W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2006

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 11 Jan 2006 10:45:56 +0100
Message-ID: <43C4D3D4.6000206@gmx.de>
To: Cullen Jennings <fluffy@cisco.com>
CC: WebDav <w3c-dist-auth@w3.org>

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

Content-Type: application/xml

<error xmlns="DAV:">
     <href>...the offending URI...</href>

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:35 UTC