WMS GetMap HEAD request error response - check response status defined

[josegar74]

If CORS is not allowed for WMS GetMap HEAD request, the error response doesn't contain the status property. Protect the related check.

Follow up of #7000

Checklist

• I have read the contribution guidelines
• Pull request provided for main branch, backports managed with label
• Good housekeeping of code, cleaning up comments, tests, and documentation
• Clean commit history broken into understandable chucks, avoiding big commits with hundreds of files, cautious of reformatting and whitespace changes
• Clean commit messages, longer verbose messages are encouraged
• API Changes are identified in commit messages
• Testing provided for features or enhancements using automatic tests
• User documentation provided for new features or enhancements in manual
• Build documentation provided for development instructions in README.md files
• Library management using pom.xml dependency management. Update build documentation with intended library use and library tutorials or documentation

[jahow]

What does that new check achieve? It seems superfluous

[fxprunayre]

If CORS is not enabled, the response object has no status

It looks like some servers add CORS header on GET and not on HEAD. Also depending on Apache config, if there is an error, then CORS header are not always present (depends on virtual host config and the set header directive).

The CORS interceptor does not make the difference between operation so it will start using the proxy for GET if an HEAD request fails (and then GET request may also be not allowed causing subsequent issues).

[josegar74]

@jahow without that check, when the response has no status (as described previously by @fxprunayre ), it fails accessing r.status, what causes the CORS interceptor to add the server in the list to use the http proxy when accessing any url from that server.

So if you are unlogged and try to add a layer from that server in the map viewer (Add layers > Services > WMS), you get the following error:

Due to the http proxy default policy to require the service to be defined in the metadata and analysed with the link analysis tool, for unlogged users. The service seems working fine with CORS for GET operations.

[jahow]

No but I meant, if r.status equals 414 then it has to be truthy; I just don't get the r.status && part

[josegar74]

@jahow see the commment from @fxprunayre in his reply:

If CORS is not enabled, the response object has no status

[jahow]

I understand but:

• if r.status is undefined then r.status === 414 will return false
• if r.status is undefined then r.status && r.status === 414 will return undefined
• if r.status is 414 then r.status === 414 will return true
• if r.status is 414 then r.status && r.status === 414 will also return true
• if r.status is 200 then r.status === 414 will return false
• if r.status is 200 then r.status && r.status === 414 will also return false

I'm just not sure this change is going to do anything at all?

[josegar74]

@jahow you are totally right, apologies. I was testing several options and I seems I got confused with the one that worked.

I just updated the code to avoid the CORS interceptor for the HEAD request, that is working fine. Doesn't seem optimal, but at least looks working fine.

[fxprunayre]

As this service is supporting CORS for GET but not for HEAD, an other option is to add the method to the requireProxy

The proxy may still be useful in some case for HEAD requests?

For the other case, when a service is not providing CORS header on HTTP errors, then it is probably more difficult and has to be properly configured on the WMS side.

[josegar74]

@fxprunayre what should contain requireProxy? The method name (HEAD) or the URL+Method?