Re: Re-using 414 status codes (related to Bug 31)

Cullen Jennings wrote:
> On 1/11/06 1:01 AM, "Julian Reschke" <julian.reschke@gmx.de> wrote:
> 
>> Cullen Jennings wrote:
>>> I think you should provide implementers advice on what to do in this case.
>> It's already saying:
>>
>>>> User agents may be able to take advantage of this
>>>> to display a meaningful error message to the user.
>> I'm not sure what else we could say...
>>
>>
>> Best regards, Julian
> 
> I was thinking of advice that answered the following ... If I am a server
> implementer, and I get a URI other than the request URI that is too big,
> what do I do?

The server should do whatever the spec says. If we...

 > 1) Remove that paragraph, thus be silent on what servers return in this
 > case, which in general would mean 400 Bad Request. This is consistent
 > with RFC2616, but doesn't give clients a mean of detecting this error
 > condition.

...the server should return a 400, and potentially an HTML response. A 
non-browser client would likely not know what to do with it.

If we...

 > 2) Keep Section 11.2 (being inconsistent with RFC2616)

the server would reply with 414 (potentially confusing clients because 
that's not what 414 is for).

If we...

 > 3) Define a precondition code that could be used with status 400, and
 > which would allow not only to describe the general problem, but also
 > could include the URI that was actually causing the problem (keep in
 > mind that URIs can appear in several places in the request headers, such
 > as "Destination" and Tagged-Lists in "If"). The exact proposal for this
 > is below.

...the server would return something like

HTTP/1.1 400 BAD REQUEST
Content-Type: application/xml

<error xmlns="DAV:">
   <uri-size-not-exceeded>
     <href>...the offending URI...</href>
   </uri-size-not-exceedeed>
</error>

and a client could then pull out both the reason (condition code) and 
the details (URI) from the body.

And again...:

 > Feedback appreciated, mine would be:
 >
 > 1) +.5
 > 2) -1 (because of inconsistency with RFC2616)
 > 3) +.5 (it doesn't hurt)

Best regards, Julian

Received on Wednesday, 11 January 2006 09:47:48 UTC