tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Darryl L. Miles" <>
Subject Re: Do URL query strings with semi-colons work with TC ?
Date Tue, 06 Sep 2005 11:04:33 GMT Not sure what 
authorative basis this has, but it did turn up from NCSA based CGI 
specifications of yesteryear.

Maybe the MIME specification for application/x-www-form-urlencoded 
wherever that is (cant find it either).

It must be noted that a URL like this is valid syntax:;foo=bar/pathseg2;foo=bar2/pathseg3;foo=bar3;foo=bar33?query=value

How the receiving HTTP server interprets the path is unspecified, and I 
don't think its mandatory for a HTTP server to support path params at 
any level.  Since JSESSIONID is being used I would say that only the 
last path parameters should be picked up and made available to the 
target servlet and an error given out to path params no part of the last 
segment (so no one tries to use them, leaving the door open for their 
implementation later in a server that would support some usage), that 
make these path params eligable for pickup:


As for precedence / override with tranditional query strings, i.e. 
should the namespaces be collsapse. sigh another issue to head scratch.


Jon Wingfield wrote:

> Aye. It just states for that, amongst others, amphersand and 
> semi-colon are reserved characters within the query string.
> This got me looking coz I assumed that the structure of the http get 
> query string was defined somewhere in rfc rather than just a convention.
> I found a few resources saying it was recommended to support ";" as a 
> delimiter;
> But I also found the likely candidate in TC that does the parsing of 
> the query string:

> Just for my peace of mind does anyone know where the "standard" use of 
> amphersand to delimit name-value pairs in a http get query string is 
> defined?
> Jon
> Darryl L. Miles wrote:
>> section 3.3 seems to be the 
>> best reference so far.
>> This RFC only specifies correct URI syntax, it does not mandate how 
>> that URI is used under any scheme (like "http:") is to be used.
>> Darryl L. Miles wrote:
>>> The reference you cite (el al) 
>>> maybe you could also cite the section I should look at.  A simple 
>>> search for "param" or "semi" yeilds no related results.  I have 
>>> spent an hour looking into the issue over the weekend and found the 
>>> specification that covers the URI scheme for "http:" from this angle 
>>> it seems to leave the part after the ? to denote the start of a 
>>> query string vague.  Which lead me to a presumption that it was HTTP 
>>> server dependant on its interpretation, since for example the 
>>> modules changed over from & to ; as the standard param delimiter 
>>> with generated URLs, providing the resulting URL talks back to 
>>> itself (the module) all will be well in the world but if it 
>>> links to a TC server then there would appear to be a problem.

Darryl L. Miles

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message