- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 12 Oct 2007 17:05:02 +1000
- To: HTTP Working Group <ietf-http-wg@w3.org>
One of the issues that I regularly see developers run up against is URI length limitations in both client and server implementations. RFC2616, section 3.2.1 covers servers pretty well; > he HTTP protocol does not place any a priori limit on the length of > a URI. Servers MUST be able to handle the URI of any resource they > serve, and SHOULD be able to handle URIs of unbounded length if > they provide GET-based forms that could generate such URIs. A > server SHOULD return 414 (Request-URI Too Long) status if a URI is > longer than the server can handle (see section 10.4.15). > and to their credit, most origin servers can be configured to handle longer URIs (although they still have a hard-coded limit). Clients, however, are not so well-covered, and that's where a lot of the pain I see comes from; some mainstream browsers limit URIs to 1k or less, IIRC, and in some cases they require far smaller URIs. Mobile browsers are particularly painful to work with, some limiting URIs to 256 bytes or less. In fact, this is made more legitimate by this text; > Note: Servers ought to be cautious about depending on URI > lengths > above 255 bytes, because some older client or proxy > implementations might not properly support these lengths. Should there be requirements or specific guidance for clients as well? Also, the text above is somewhat specific to origin servers ("any resource they serve"); something for proxies may be helpful as well. Cheers, -- Mark Nottingham http://www.mnot.net/
Received on Friday, 12 October 2007 07:07:02 UTC