Status is wrong on exceptions

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Call a service URL that raises an exception like
http://incf-dev.crbs.ucsd.edu:8080/atlas-whs?service=WPS&version=1.0.0&request=E
xecute&Identifier=ListSRS 
(typo in identifier) or
http://incf-dev.crbs.ucsd.edu:8080/atlas-whs?service=WPS&version=1.0.0&request=E
xecute&Identifier=DescribeSRS
(required argument missing)

2. Look at the response header

What is the expected output? What do you see instead?

I would expect the status being: 400 Bad Request

I see the status being: 403 Forbidden

According to
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

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

whereas 403 indicates "The server understood the request, but is refusing to 
fulfill it. Authorization will not help and the request SHOULD NOT be repeated. 
If the request method was not HEAD and the server wishes to make public why the 
request has not been fulfilled, it SHOULD describe the reason for the refusal 
in the entity. If the server does not wish to make this information available 
to the client, the status code 404 (Not Found) can be used instead."

Original issue reported on code.google.com by [email protected] on 21 Sep 2010 at 10:57

[GoogleCodeExporter]

Hi Raphael,

Thanks for posting the issues. We really appreciate that. 

Could you please include Ilya([email protected]) or me([email protected]) in the 
CC list when you create a new issue so that we get notified by email.

The error message that you see is by design as per the WPS specification where 
we examine the URL pattern in the web service code. If it does not satisfy the 
URL pattern, it errors out otherwise returns the expected response. Please see 
below the working URL: 

http://incf-dev.crbs.ucsd.edu:8080/atlas-whs?service=WPS&version=1.0.0&request=E
xecute&Identifier=ListSRSs

Please let me know if you have any questions?  

Sincerely,
Asif Memon

Original comment by [email protected] on 6 Oct 2010 at 8:32

[GoogleCodeExporter]

Looks like I wasn't clear enough, sorry:

I'm totally fine with an error being raised in the situations mentioned above. 
What I suggest for consideration though is to slightly change the status in the 
HTTP header from 403 (meaning "The server understood the request, but is 
refusing to fulfill it.") to 400 (meaning "malformed syntax") which I consider 
more appropriate in those situations. That's all.

Original comment by [email protected] on 11 Oct 2010 at 9:05

[GoogleCodeExporter]

Returning to this for the Degree-based services now: when calling 

http://incf-dev-local.crbs.ucsd.edu/whs/atlas?service=WPS&version=1.0.0&request=
Execute&Identifier=DescribeSRS

aka omitting a required argument (like DataInputs=srsName=Mouse_WHS_0.9) 
we now get status 200 OK in the HTTP response header and the error signaling 
moved into the XML response. 

<wps:Status 
creationTime="2011-03-03T09:57:09.378Z"><wps:ProcessFailed><ows:ExceptionReport 
xsi:schemaLocation="http://www.opengis.net/ows/1.1 
http://schemas.opengis.net/ows/1.1.0/owsExceptionReport.xsd" 
version="1.1.0"><ows:Exception 
exceptionCode="NoApplicableCode"><ows:ExceptionText>Unexpected exception 
occured</ows:ExceptionText></ows:Exception></ows:ExceptionReport></wps:ProcessFa
iled></wps:Status>

Without checking I assume that this is WPS compliant but I actually liked the 
error being signaled in the HTTP header as well. 

Is this something we can control or are we bound by the WPS specs here?

Other than that it would of course be great if the error message were a bit 
more specific.

Original comment by [email protected] on 3 Mar 2011 at 10:02

[GoogleCodeExporter]

Nitpicking: the phrasing quoted above "Unexpected exception occured" contains a 
typo in "occurred" (second 'r' missing)

Original comment by [email protected] on 3 Mar 2011 at 10:58