Bill de hÓra wrote:
James M Snell wrote:
HTTP/1.1 5xx Some Error
Content-Type: application/error+xml
Content-Length: nnnn
<error xmlns="urn:some-namespace">
<code scheme="{URI indicating error code scheme}">{scheme defined
error code}</code>
<summary>{human readable summary of the error</summary>
<action>{URI indicating an action taken by the server in response to
the error}</action>
{namespaced extension elements}*
</error>
What should happen:
- when the http response is 200 and the code in the XML is '503'?
- when the http response is 200 and the code in the XML is 'snafu'?
- when the http response is 400 and the code in the XML is
'java.lang.ClassNotFoundException'?
Putting codes in two places and/or two layers in a response raise
similiar issues to putting methods in two places and/or two layers in a
request. In the general case - what should happen when the http response
is X and the code in the XML is 'Y' - I think is a non-trivial problem.
Yes, I'm struggling with this also. Part of my brain wants to make
<code /> optional and strictly informational in favor of the HTTP
response code. However, another part of my brain wants this mechanism
to be generally reusable across other transports (e.g. XMPP) making it
difficult to rely on consistent error codes in the lower layers. I
think the clear solution is that the HTTP response code should take
precedence in this case. If the <code /> value does not match up with
that code, then the content producer is just being silly and the
consumer has to figure out on their own what to do.
Does it make sense to require that <error /> MUST NOT be returned when
the HTTP response code is anything but 4xx or 5xx?
- James
