[hunchentoot-devel] Re: Hunchentoot's query parameter seperator

[Ralf Mattes]

On Sat, 2007-11-24 at 08:43 -0700, Robert Uhl wrote:
> Edi Weitz <edi at agharta.de> writes:
> >
> > So, to everyone on the list - what's your experience with semicolons
> > as query string separators?
> 
> I've used them a lot; they're my preferred method of separating query
> args.

I personally never ever saw them used. 

> > Is this normal or esoteric?
> 
> Something less than normal and more than esoteric, methinks.

I disagree - the RFC
(http://www.w3.org/TR/html4/interact/forms.html#form-content-type) is
actually rather clear about this. Section 17.13.4 "Form content types"
reads as follows:

 * application/x-www-form-urlencoded  
   This is the default content type. Forms submitted with this content
   type must be encoded as follows:

     1. Control names and values are escaped. Space characters are
        replaced by `+', and then reserved characters are escaped as
        described in [RFC1738], section 2.2: Non-alphanumeric characters
        are replaced by `%HH', a percent sign and two hexadecimal digits
        representing the ASCII code of the character. Line breaks are
        represented as "CR LF" pairs (i.e., `%0D%0A').
     2. The control names/values are listed in the order they appear in
        the document. The name is separated from the value by `=' and
        name/value pairs are separated from each other by `&'. 

And that's it. Nowhere does it even mention the use of #\; as a
separator of name/value pairs.

> > And, even more interesting, does any client out there actually use
> > this convention?
> 
> The clients don't create URL args; those are generated by the site in
> question or by the user's typing.

??? I think you must missunderstand something here - of course the
client application needs to construct an URL every time a user fills out
a html form that uses the GET method. Please refer to section 
17.13.3 "Processing form data" of the RFC.

> For the same reason, I'm not certain that compatibility is a worry: if
> the client is requesting a URL the server previously served, surely that
> URL is A-OK.

GET urls are usually _not_ served by the server but generated by the
client application. How should a server process the following request:

 GET /foo/bar?name1=value1;&name2=value2

Do we expect 'name1' -> 'value1;' and 'name2' -> 'value2' or 
do we expect 'name1' -> 'value1'  and ';name2' -> 'value2'????
  

 Cheers, Ralf Mattes