W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 31 Dec 2005 13:01:37 +0100
Message-ID: <43B67321.3080908@gmx.de>
To: w3c-dist-auth@w3.org

Hi,

(see also <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=31>).

In Section 11.2, draft 09 of RFC2518bis currently says 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-09.html#rfc.section.11.2>):


11.2 414 Request-URI Too Long

This status code is used in HTTP 1.1 only for Request-URIs, because full 
URIs aren't used in other headers. WebDAV specifies full URLs in other 
headers, therefore this error MAY be used if the URI is too long in 
other locations as well.


I note that this statement is non-compliant to RFC2616 (which says that 
414 is just for the case where a Request-URI is too long, that's it). 
The only good reason for being inconsistent with RFC2616 would be if 
this would be documenting existing practice that can't easily be fixed. 
So is anybody aware of servers that do this?

In our last conference call, we also discussed that although this 
problem may be nothing a user agent can fix automatically, it 
nevertheless may be good if it could display a meaningful error message 
to the user.

To go forward, there seem to be at least three choices:

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.

2) Keep Section 11.2 (being inconsistent with RFC2616)

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.

Feedback appreciated, mine would be:

1) +.5
2) -1 (because of inconsistency with RFC2616)
3) +.5 (it doesn't hurt)

Feedback appreciated, Julian


-- proposal for precondition code --

15.7 DAV:uri-reference-length-within-limits (precondition)

Servers MAY restrict the length of URI references in certain header 
fields, such as "Destination" or "If".  This condition code can be used 
to signal this condition, and also to include the actual URI reference 
causing the problem.  User agents may be able to take advantage of this 
to display a meaningful error message to the user.

        <!ELEMENT uri-reference-length-within-limits (href)* >

Servers SHOULD insert DAV:href elements for the URI reference(s) that 
caused the problem.
Received on Saturday, 31 December 2005 12:03:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:12 GMT