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

Of those three options, 2 and 3 give clear advice. You could change 1 to
also give clear advice by saying the "server should return a 400 and
potentially and HTML response".

I was not really saying which one was good other than whatever thing you
decide, give clear advice on what a server should do and what a client can
rely on. 


On 1/11/06 1:45 AM, "Julian Reschke" <julian.reschke@gmx.de> wrote:

> 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 10:10:19 UTC