search

opengeospatial / ets-wcs20

Executable Test Suite for WCS 2.0.1
Other
1 stars 2 forks source link

Incorrect 404 Error Response #6

Closed bermud closed 3 years ago

bermud commented 9 years ago

req24: When a WCS server encounters an error while performing a GetKVP DescribeCoverage operation it shall return an exception report message chosen as specified.

req41: When a WCS server encounters an error while performing a GetKVP GetCoverage operation it shall return an exception report message as specified. Test HTTP status codes for OGC Exceptions.

The tests expect a status code of 404 because this is what the spec clearly stipulates in Tables 15 and 20 (OGC 09-110r4). If 404 is returned client cannot see the OGC Exceptions, because 404 is not found.

Shouldn't it be 400 (Bad Request), when an exception occurs?

Also searching on the web, it seems that lots of servers if they want to provide an application (e.g. WCS) error prefer to use a 200 (OK), for the servers to be able to provide the application exception error report. It seems Esri services and GeoServer throw 200 (OK), when exceptions occur.

bermud commented 9 years ago

@pebau, We think this should be discussed in the WG.

bermud commented 9 years ago

OWS Common (OGC 06-121r9) states different codes and examples. I think the server should return 400.

400 Bad Request The server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).

404

yyx350 commented 9 years ago

According to OGC 06-121r9,"... OWS instance shall set the HTTP response’s status code to the corresponding value for the given exceptionCode values, as shown in Table 28", 400 is the code for generic OWS exceptions, such as MissingParameterValue, InvalidParameterValue, VersionNegotiationFailed, and InvalidUpdateSequence. Additionally, OWS spec suggests that "OWS specifications specifying additional exceptionCode values shall provide a corresponding HTTP status code value for every new exceptionCode" In this case, a new HTTP status code value is welcomed for a specific exception that does not concluded in OWS' Table 28.

OGC 09-110r4 is an instance of OWS, it inherits the exception req as specified in Clause 8 of [OGC 06-121r9], and it adds additional WCS 2.0 status code 404 in its Table 15 & 20, including NoSuchCoverage, emptyCoverageIdList, InvalidAxisLabel and InvalidSubsetting for the cases that coverage resources can not be found. Further exceptions are specified in its extentions if the error occurs while performing some extension functionality.

A 404 error indicates that the server itself was found, but that the server was not able to retrieve the requested object according to the given URI,see http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

yyx350 commented 9 years ago

servers can typically be configured to display a customised 404 error page, e.g. NoSuchCoverage, emptyCoverageIdList, and etc. Otherwise, the page will show the default "404 not found"

pebau commented 9 years ago

Just one facet on 200: I find it dangerous to return 200 if obviously something has gone wrong. In this respect, 404 seems appropriate to me when I think of a server saying: "something has gone wrong, but on a higher semantic level, so go see there what was the root cause." Also the definition in https://en.wikipedia.org/wiki/HTTP_404 makes sense to me: "the client was able to communicate with a given server, but the server could not find what was requested." "Bad request" IMHO refers to a bad syntax - again citing Wikipedia https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_Client_Error I find "The server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing)." So nothing about "item not found" etc.

pebau commented 9 years ago

If, however, 404 is perceived as being wrong indeed then IMHO we should escalate it to OAB to get a generic advice that all services can follow, as this to me feels like a fundemantal design decision.

bermud commented 9 years ago

We should follow OWS-Common and wikipedia [1] and return a 400 for client request errors. It's clear the difference between a 400 (Bad Request) and a 404 (Not Found). If the request was able to reach the server implementing OGC services, then the service should return a 400.

RFC2616 [2] also suggests that 404 should not be the response. "This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable." The OGC request are more "malformed syntax" related this is error 400.

Peter, if you really need to raise this issue to the OAB, please do so.

[1] https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_Client_Error [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

pebau commented 9 years ago

Hi coverage activists,

an issue has been raised by Luis, it concerns the response code in certain error cases [1]. WCS Core specifies, in its exception table, to return a 404 in cases an item cannot be found. This includes cases like: no such coverage; invalid axis label; invalid subsetting. When designing WCS Core the perception was that these cases are different from a "malformed request" (400), aka syntax error, and hence deserve a separate error code.

Luis now is of the opinion that 404 is not appropriate according to HTTP best practices (see his explanation below), and that OWS Common 2 mandates a 400 (note that OWS Common 2 had been released after the resp. decision on WCS 2 had been made in the WCS.SWG).

Effectively, we end up with these variants:

I would like to hear opinions to get to a consolidated, resilient decision, resulting in a Change Request if deemed necessary.

best, Peter

[1] https://github.com/opengeospatial/ets-wcs20/issues/6

On 03/16/2015 11:56 PM, Luis Bermudez wrote:

We should follow OWS-Common and wikipedia [1] and return a 400 for client request errors. It's clear the difference between a 400 (Bad Request) and a 404 (Not Found). If the request was able to reach the server implementing OGC services, then the service should return a 400.

RFC2616 [2] also suggests that 404 should not be the response. "This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable." The OGC request are more "malformed syntax" related this is error 400.

Peter, if you really need to raise this issue to the OAB, please do so.

[1] https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_Client_Error [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

— Reply to this email directly or view it on GitHub https://github.com/opengeospatial/ets-wcs20/issues/6#issuecomment-81978108.

Dr. Peter Baumann

nmtoken commented 9 years ago

Certainly giving an HTTP 200 OK response when serving an error message of any kind is wrong.

I think giving an HTTP 400 Bad Request for a response where the syntax of the request is essentially correct but the values provided are wrong is also incorrect. In such a situation an HTTP 404 Not Found is more correct, other responses could apply when, for example, a coverage has been removed or renamed, an HTTP 410 Gone response could be given (though how the server would know that the request was for a removed id I don't know).

pebau commented 9 years ago

interesting, so this supports the status quo of WCS. Any further voices? -Peter

On 03/17/2015 02:40 PM, nmtoken wrote:

Certainly giving an HTTP 200 OK response when serving an error message of any kind is wrong.

I think giving an HTTP 400 Bad Request for a response where the syntax of the request is essentially correct but the values provided are wrong is also incorrect. In such a situation an HTTP 404 Not Found is more correct, other responses could apply when, for example, a coverage has been removed or renamed, an HTTP 410 Gone response could be given (though how the server would know that the request was for a removed id I don't know).

— Reply to this email directly or view it on GitHub https://github.com/opengeospatial/ets-wcs20/issues/6#issuecomment-82357298.

Dr. Peter Baumann

pebau commented 9 years ago

(forgot to cc to the coverages list)

On 03/18/2015 06:53 PM, Peter Baumann wrote:

interesting, so this supports the status quo of WCS. Any further voices? -Peter

On 03/17/2015 02:40 PM, nmtoken wrote:

Certainly giving an HTTP 200 OK response when serving an error message of any kind is wrong.

I think giving an HTTP 400 Bad Request for a response where the syntax of the request is essentially correct but the values provided are wrong is also incorrect. In such a situation an HTTP 404 Not Found is more correct, other responses could apply when, for example, a coverage has been removed or renamed, an HTTP 410 Gone response could be given (though how the server would know that the request was for a removed id I don't know).

— Reply to this email directly or view it on GitHub https://github.com/opengeospatial/ets-wcs20/issues/6#issuecomment-82357298.

Dr. Peter Baumann

  • Executive Director, rasdaman GmbH Bremen (HRB 26793) www.rasdaman.com, mail: baumann@rasdaman.com tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
  • Professor of Computer Science, Jacobs University Bremen www.faculty.jacobs-university.de/pbaumann mail: p.baumann@jacobs-university.de tel: +49-421-200-3178, fax: +49-421-200-493178 "A brilliant idea is a job halfdone."

Dr. Peter Baumann

tastle commented 9 years ago

I'm here because I caught Peter's share to the coverages mailing list, which I follow :)

404 Not Found The requested resource could not be found but may be available again in the future. Subsequent requests by the client are permissible.

http://example.com/hello.txt

So hello.txt is the resource. If I extrapolate beyond that with a query string (for the point of argument)

http://example.com/hello.txt?start=1&end=20

The resource is still hello.txt, and the query is everything afterwards.

So unless the resource (which might be functioning as a service interface) vanished, a query shouldn't trigger a 404.

The word "resource" means something, and I'm wondering if that is what is missing in this discussion.

https://www.ietf.org/rfc/rfc2616.txt resource A network data object or service that can be identified by a URI, as defined in section 3.2. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, and resolutions) or vary in other ways.

pebau commented 9 years ago

oops, now we have several threads: OGC WCS list, Coverages list, and here. Sorry for the confusion, repeating my WCS.SWG posting here, that should answer the above raised question: --- snip ---------------- an issue has been raised by Luis, it concerns the response code in certain error cases [1]. WCS Core specifies, in its exception table, to return a 404 in cases an item cannot be found. This includes cases like: no such coverage; invalid axis label; invalid subsetting. When designing WCS Core the perception was that these cases are different from a "malformed request" (400), aka syntax error, and hence deserve a separate error code.

Luis now is of the opinion that 404 is not appropriate according to HTTP best practices (see his explanation below), and that OWS Common 2 mandates a 400 (note that OWS Common 2 had been released after the resp. decision on WCS 2 had been made in the WCS.SWG).

Effectively, we end up with these variants:

I would like to hear opinions to get to a consolidated, resilient decision, resulting in a Change Request if deemed necessary. --- snip ----------------

nmtoken commented 9 years ago

10.4.1 400 Bad Request

The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.

10.4.5 404 Not Found

The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.

Under the HTTP specification an HTTP URL includes the query:

3.2.2 http URL

The "http" scheme is used to locate network resources via the HTTP protocol. This section defines the scheme-specific syntax and semantics for http URLs.

http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

So using query parameters to identify a resource is just as valid as not doing so.

So this gives a resource:

http://earthserver.bgs.ac.uk/rasdaman/ows?service=WCS&Request=DescribeCoverage&version=2.0.1&CoverageId=glasgow_bron_t&

but this doesn't

http://earthserver.bgs.ac.uk/rasdaman/ows?service=WCS&Request=DescribeCoverage&version=2.0.1&CoverageId=glasgow_bron_z&

The syntax is the same between the two so the exception report here shouldn't be HTTP 400 because the error is not in the syntax, it is the resource identifier that is incorrect.

It is no different between asking for http://earthserver.bgs.ac.uk/home.html and http://earthserver.bgs.ac.uk/nohome.html, same syntax but only one of these resources exist.

From: tastle [notifications@github.com] Sent: 18 March 2015 19:10 To: opengeospatial/ets-wcs20 Cc: Passmore, James H. Subject: Re: [ets-wcs20] Incorrect 404 Error Response (#6)

I'm here because I caught Peter's share to the coverages mailing list, which I follow :)

404 Not Found The requested resource could not be found but may be available again in the future. Subsequent requests by the client are permissible.

http://example.com/hello.txt

So hello.txt is the resource. If I extrapolate beyond that with a query string (for the point of argument)

http://example.com/hello.txt?start=1&end=20

The resource is still hello.txt, and the query is everything afterwards.

So unless the resource (which might be functioning as a service interface) vanished, a query shouldn't trigger a 404.

The word "resource" means something, and I'm wondering if that is what is missing in this discussion.

https://www.ietf.org/rfc/rfc2616.txt resource A network data object or service that can be identified by a URI, as defined in section 3.2. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, and resolutions) or vary in other ways.

� Reply to this email directly or view it on GitHubhttps://github.com/opengeospatial/ets-wcs20/issues/6#issuecomment-83124585.

This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.

tastle commented 9 years ago

I believe there needs to be some consensus as to what the "resource" is. I think understanding this will answer which error code applies. I see that some people believe that the resource is the coverage. I'm here to question that. I believe the resource is the web service and you're providing modifiers to the service to produce different types of responses, some of which may be coverages.

http://tools.ietf.org/html/rfc2396 Resource A resource can be anything that has identity. Familiar examples include an electronic document, an image, a service (e.g., "today's weather report for Los Angeles"), and a collection of other resources. Not all resources are network "retrievable"; e.g., human beings, corporations, and bound books in a library can also be considered resources.

Let's say you have: http://earthserver.bgs.ac.uk/rasdaman/ows. That is a resource. The question is, what is that resource? In this case, the resource is a web service. It isn't a coverage, and that's a key difference between OGC Web Services (KVP) and how typically RESTful services are patterned. You'll often find that RESTful web services (patterned on HTTP) represent data as if the data actually existed as files on a disk on some server, and the query can act as a modifier to each resource (if supported).

It's true that http://earthserver.bgs.ac.uk/rasdaman/ows?service=WCS&Request=DescribeCoverage&version=2.0.1&CoverageId=glasgow_bron_t& is a location to a resource (it is a URL), the query part is designed to act as a modifier of service behaviour. It's good to keep in mind that the bare-minimum needed to describe a resource in HTTP (based on the grammar in the RFC 2616) is "http://host".

Best wishes!

nmtoken commented 9 years ago

I think we should exclude in the debate how a RESTful service works vs any other architecture, a RESTful service patterned on HTTP, uses HTTP methods and hypermedia types to allow access to resources, there are no special URI patterns required within a RESTful architecture. Here, we need to just concentrate on what's allowed in HTTP.

I agree that http://earthserver.bgs.ac.uk/rasdaman/ows is a resource and that resource is a service. That service provides access to collection of coverages each of which are resources. The WCS service exists to provide access to the actual data, (or more strictly a copy of the data). I don't see a difference here between a host http://example.com:80/ being a resource (a web server) providing access to a collection of HTML pages, all individually resources, such as http://example.com/hello.txt or http://example.com/hello...

Cheers

This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.

pebau commented 9 years ago

indeed, we have nested resources here: the service as such, and coverages, and bands or regions within a coverage. For each situation there is an individual error code, and 404 was chosen by WCS on coverage/sub-coverage level with the idea that the request as such is correct, but there happen to be no data (no such coverage, not that region in space/time, no such band). Notably, at a later time there might be such a coverage or - in case of a timeseries - a timeslice.

A theory: As this hierarchy of service -> object is continued only by coverages (object -> components) this might simply have been overlooked in OWS Common when they uniformly mandated 400.

-Peter

bermud commented 9 years ago

Hi Peter, Our issue of concern is a WCS request (GetKVP DescribeCoverage operation). This operation (with its variants) are "Resources". If a WCS server is able to get the request, then it is able to understand that is a WCS operation and that a client is trying to get a specific resource.

Do we agree that If a parameter (key or value) is incorrect, then the code should be 400 Bad Request?

nmtoken commented 9 years ago

I just can't see how an incorrect value can count as a bad request; the issue in such a case is not that the server can't understand the request due to malformed syntax (aka bad request) . The server understands the request, it can't supply the resource because it doesn't exist, this is analogous to web server not being able to provide a web page or an image/stylesheet/javascript file etc 'in' a web page.

pebau commented 9 years ago

Hi Luis,

this is an ongoing issue which also has seen quite some discussion in OAB.

My understanding is that it defines specific codes for specific situations which arise from the particular semantics. But obviously (?) other codes can occur as well, for example from lower-level communication layers. So I'd agree that a 400 can occur, eg: http://www.acme.com/wcs?SERVICE=WCS&VERSION=2.0&REQQEST=blabla OTOH, if a value on the semantic level of WCS is incorrect we have the 404:

http://www.acme.com/wcs?SERVICE=WCS&VERSION=2.0&REQUEST=DescribeCoverage&COVERAGEID=NotExistentCoverage This helps applications to understand better what has happened, and eventually to react automatically. Same for 401, 402, 403, 423, 429, 500, etc.

cheers, Peter

On 07/01/15 17:06, Luis Bermudez wrote:

Hi Peter, Our issue of concern is a WCS request (GetKVP DescribeCoverage operation). This operation (with its variants) are "Resources". If a WCS server is able to get the request, then it is able to understand that is a WCS operation and that a client is trying to get a specific resource.

Do we agree that If a parameter (key or value) is incorrect, then the code should be 400 Bad Request?

— Reply to this email directly or view it on GitHub https://github.com/opengeospatial/ets-wcs20/issues/6#issuecomment-117710215.

Dr. Peter Baumann

pebau commented 7 years ago

hm, so after a long and winding discussion we still have no change request, so 404 still is the valid resposne as per spec. Actually, this CR should go against OWS Common.

pebau commented 7 years ago

I am too blind to find out how to reassign from WCS to OWS Common - can someone please do this? thx, Peter

lgoltz commented 6 years ago

Can someone point out which changes are required in the ETS? Or can we close this ticket as the ETS behaves accordingly to the specification?