James M Snell wrote:
> 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.
Precedent: That didn't work out for content-encoding.
I think SOAP faulting enables clients to ignore the HTTP code altogether.
I don't know how valuable reusable error codes of this kind are - my
assumption has been they're specific to application protocols (which is
wandering into protocol neutrality transport/transfer territory).
> 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.
My guess is that they'll take the served XML at face value and drop the
HTTP code. In any case, putting consumers in a position to have to
figure out what to do, by design, is not sound, I would want to be able
to emit an 'Indecipherable Architecture Error' - but to who?
> Does it make sense to require that <error /> MUST NOT be returned when
> the HTTP response code is anything but 4xx or 5xx?
It does, but it doesn't give enough constraints to narrow the problem.
The problem is still "what should happen when the http response is X and
the code in the XML is 'Y'?" You only need one value for each to reduce
robustness.
cheers
Bill
