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

I think you should provide implementers advice on what to do in this case.


On 12/31/05 4:01 AM, "Julian Reschke" <julian.reschke@gmx.de> wrote:

> 
> 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.se
> ction.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 Wednesday, 11 January 2006 07:54:14 UTC