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

From: Cullen Jennings <[email-masked]>
Date: Tue, 10 Jan 2006 23:54:22 -0800

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

On 12/31/05 4:01 AM, "Julian Reschke" <[email-masked]> 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.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 11 Jan 2006 10:01:10 +0100

It's already saying:

 >> User agents may be able to take advantage of this

I'm not sure what else we could say...

Best regards, Julian

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 11 Jan 2006 01:40:57 -0800

> I'm not sure what else we could say...

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?

---

From: Julian Reschke <[email-masked]>
Date: Wed, 11 Jan 2006 10:45:56 +0100

> implementer, and I get a URI other than the request URI that is too big,

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

 > with RFC2616, but doesn't give clients a mean of detecting this error

...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...

 > as "Destination" and Tagged-Lists in "If"). The exact proposal for this

...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.

Best regards, Julian

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 11 Jan 2006 02:10:23 -0800

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.