[sclug] URL encoding/decoding question

[Roland Turner SCLUG]

On Sun, 2006-02-19 at 19:06 +0000, Dickon Hood wrote:

> Er, IIRC, HTTP URIs are only guaranteed to work for up to 256
> characters
> or so,

Not quite.

RFC 2616 3.2.1

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

      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.

In other words, not only is it not MUST, it's not even SHOULD, just
"ought", which doesn't even rate a definition in IETF's compliance
dictionary.

>  with most clients and servers expected to cope with 1KB.

I recall that being a rule of thumb a few years ago, yes.

> This is one reason for the METHOD=POST HTML form parameter.

Hmm. Sort of. POST exists in order to implement quite different
semantics to GET, although it is ordinarily assumed (in particular see
RFC 2616 10.4.15) that the upper likely bound for the length of GET
requests is far smaller than it is for POST requests.

(This is not to say that sloppy and/or ignorant coders won't abuse
HTTP's design, they will, much as they'll construct SQL statements on
the fly with a combination of template text and unsanitised inputs from
web-browsers...)

> There's nothing wrong with URL-encoding arbitrary strings, though, to
> cope with storage mechanisms that can't handle embedded linefeeds or
> spaces or whatnot.  As I said before, it's a technique I've used in
> the past (storing such strings in RFC822 headers, for example),

An interesting application. Where you really don't have a choice, I'd be
inclined to agree.

>  but I wouldn't use it for storing data in an SQL database.

No.

- Raz