HTTP response headers matching should be case-insensitive

[igea-jure]

When testing a WMS service, we've encountered many failed tests that were caused by checking case-sensitive HTTP response headers. According to HTTP/1 specification, all HTTP headers are case-insensitive. According to HTTP/2, they should all be in lowercase.

We are using HAProxy as our reverse proxy, which follows this specifications and converts all HTTP headers to lowercase.

Example: our view service, located here, fails at test at51-getmap-request-parameter at assertion Fail if service does not return OWS Exception Report. This assertion checks the content of HTTP response header Content-Type (note the word capitalization). Since our response headers are lowercase (i.e. content-type), the test fails. We believe this is not correct behaviour. Link to Test report from official INSPIRE validator is here.

Solution (for testing view services):

• Most response headers are read with method messageExchange.getResponseHeaders().get(...) - these should probably be changed to messageExchange.getResponseHeaders().getCaseInsensitive(...) (docs).
• I've also found calls to testRequest.response.responseHeaders.get(...). Converting these calls to testRequest.response.responseHeaders.getCaseInsensitive(...) should also do the trick, since it seems that the responseHeaders is also an instance of object StringToStringsMap (just like above).

We have ran into this issue when testing view services, but the same issue might also exist in other tests.

[igea-jure]

We've already fixed our local version of file https://github.com/inspire-eu-validation/ets-repository/blob/master/service/vs-wms-soapui-project.xml. Is there any way we can submit it to the official repo, i.e. via pull request or some other method?

[igea-jure]

Pull request: inspire-eu-validation/ets-repository#644

[dperezBM]

Dear @igea-jure,

First of all, please apologise for the late response. We have reviewed and tested your PR and looks great for us.

However, we cannot accept it directly, because your origin base branch is 'staging' and this branch contains accepted and not accepted issues. We updated the contribution guidelines to clarify this misunderstanding.

We created a new branch from next (issue-558) and added your changes here.
We also created a branch from staging (issue-558-staging) and merged 'issue-558' in order to fix the conflicts between next and staging. We will merge this Pull Request firstly to staging. Once the pull request is merged, we will ask you to validate the changes on our staging instance, we will merge 'issue-558' to next and mark the issue as solved.

Thank you very much for your collaboration.
David.

[dperezBM]

Dear @igea-jure,

We deployed a correction on our staging instance. Could you please check if this is valid for you?

Thank you and best regards.
David.