Header validation issues in CORS and linkset+json tests

[louisaxel-ambroise]

Hi,

Thanks for this tool, it's really helpful to test a custom GS1 resolver implementation!

I'm seeing two failing tests related to response header validation in my implementation, and I'd like to check if the test expectations are aligned with the specifications.

1. CORS headers validation

The failing test is:

"SHALL support HTTP 1.1 (or higher) GET, HEAD and OPTIONS requests."

It appears the test suite checks for the Access-Control-Allow-Methods header in the GET response. According to the CORS specification, this header is only required in response to a preflight OPTIONS request. For a simple GET request, the server is only required to return Access-Control-Allow-Origin (assuming an Origin header is present in the request).
Would it be possible to update the test to:

• Send a valid OPTIONS preflight request, and
• Validate Access-Control-Allow-Methods in the OPTIONS response instead?

This would better align the test behavior with the CORS specification.

2. application/linkset+json Content-Type comparison

The second issue relates to this requirement:

"If the HTTP Accept header is application/linkset+json, the resolver SHALL return the linkset serialised as JSON as defined by RFC 9264."

The test currently compares the Content-Type header against the literal string application/linkset+json. However, this causes the test to fail if a charset is included. In my case, the response header is application/linkset+json; charset=utf-8, which is a valid value.
Could it be possible for the test to check that the header starts with or contains application/linkset+json instead of an exact match?

Thanks again for the tool, and I'm happy to provide more details or help resolve these issues if needed!

[philarcher]

Thank you very much @louisaxel-ambroise - that's super-helpful.

Of course you are right in both respects. I will make these changes as soon as I can.