search

Wireless-Innovation-Forum / 6-GHz-AFC

This repository contains code and data for testing the compliance of Automated Frequency Coordinator (AFC) software. The AFC is defined by the FCC in proceeding 18-295 on Unlicensed Use of the 6 GHz Band. This repository contains procedures, documentation, and tests for such software, and for the devices authorized by it. To contribute, please first read the CONTRIBUTING file in the repository for instructions.
14 stars 3 forks source link

Relax HTTP status code check #41

Closed AEgbert closed 1 year ago

AEgbert commented 1 year ago

UPDATE: Based on additional feedback, this PR has been revised to only permit HTTP code 400 if all provided responses indicate an error and warn on instances where a mixture of valid/invalid requests are provided in a single request message. Revised PR notes are provided in the comments below.

Original PR Description:

SDI is ambiguous on HTTP status code for many cases. Specifically, it's unclear what the status code should be if the response message contains any responses that indicate a non-SUCCESS code.

Originally, this harness assumed that a 2XX HTTP code would be returned for any response that did not meet one of the explicit criteria listed in the SDI (missing HTTP headers, bad URL, missing SDI message). However, it was requested that an AFC be permitted to return a 400 HTTP status code (BAD REQUEST) alongside any non-SUCCESS SDI response codes.

Note that as multiple requests may be addressed in a single response message, an HTTP status code of 400 is not sufficient to determine if a given request contains an error or not--the individual SDI response code would still need to be validated on a per-request basis. However, this harness assumes that an HTTP code of 400 must be accompanied by at least one non-SUCCESS SDI response code.

For example, if an AFC response satisfies a mask that expects only SUCCESS codes, but the AFC response includes any non-2XX HTTP status code, then the test result will still be UNEXPECTED. If an AFC response satisfies a mask that expects any non-SUCCESS code, then the harness will accept 2XX or 400 as the HTTP status code for an EXPECTED result.

This commit also fixes a typo in the masks directory README and adjusts some of the log messages in test_main (either typo fixes or adjustments for new HTTP code handling).

AEgbert commented 1 year ago

Revised PR Description

SDI is ambiguous on HTTP status code for many cases. Specifically, it's unclear what the status code should be if the response message contains any responses that indicate a non-SUCCESS code. Questions regarding how mixtures of valid and invalid requests should be handled by a response have also been raised.

Relax HTTP status code check

Originally, this harness assumed that a 2XX HTTP code would be returned for any response that did not meet one of the explicit criteria listed in the SDI (missing HTTP headers, bad URL, missing SDI message). However, it was requested that an AFC be permitted to return a 400 HTTP status code (BAD REQUEST) alongside non-SUCCESS SDI response codes.

Because WINNF-TS-3007 V1.2.0 Section 6.3.5 states that an HTTP status code other than 200 shall be interpreted as a failure to obtain a list of available frequencies or channels, this harness will only permit HTTP code 400 if all responses within a response message indicate an error, as a combination of HTTP 400 alongside any SDI SUCCESS codes is contradictory.

For example, if an AFC response satisfies a mask that expects any SUCCESS codes, but the AFC response includes any non-2XX HTTP status code, then the test result will still be UNEXPECTED. If an AFC response satisfies a mask that expects only non-SUCCESS codes, then the harness will accept 2XX or 400 as the HTTP status code for an EXPECTED result.

Warn on mixed valid/invalid requests

Not all AFC systems may respond to request messages containing mixtures of valid and invalid requests in the same fashion. For instance, one AFC may reply to each message individually (providing SUCCESS and non-SUCCESS codes as applicable), while another (in order to respond with HTTP code 400) may drop/exclude any responses that would have contained a SUCCESS code from the returned response message (sending back only those responses indicating an SDI error).

For this reason, the harness now warns when validating requests that contain mixtures of valid and invalid requests. Test results for such a request will rely on the chosen interpretation (drop valid requests if any are invalid, or respond to all requests) used to generate the mask file.

Other changes

This commit also improves the robustness of the list-of-dictionaries to list-of-dataclasses conversion, corrects some log messages and log levels, removes a (presumably) unnecessary repeated try/except clause in clean_nones() and fixes a typo in the mask directory README.