The other day [1] I mentioned LID (Lightweight IDentity) [2] and the problems I saw with the URL (Uniform Resource Locator)s they were using as part of the processing. I wrote to Johannes Ernst [3], who is the principle architect of LID (Lightweight IDentifier) about the problem and after an exchange, I wrote the following, which explains part of the problem:
**To:** Johannes Ernst < XXXXXXXXXXXXXXXXX> > **From:** <sean@conman.org> > **Subject:** Re: Question about the code for LID > **Date:** Wed, 2 Feb 2005 21:56:15 -0500 (EST) >
It was thus said that the Great Johannes Ernst once stated:
> > > > > > > > > Good catch. I recall we had a discussion on that and couldn't quite figure out which way was the right way …
> > >
> > If you are trying to send parameters both as part of the URL and with a POST, the URL should be of the form:
> >
> > http://lid.netmesh.org/liddemouser/;xpath=...;action=...
> >
> You seem to be the person to ask: where is it defined that URL parameters and POST parameters in combination should be used that way? I recall we looked and couldn't find anything, but maybe you would know?
>
Well, I've checked RFC-1808 (Relative Uniform Resource Locators) [4], RFC-2396 (Uniform Resource Identifiers (URI): Generic Syntax) [5] and RFC-3986 (Uniform Resource Identifier (URI): Generic Syntax) [6], and as I interpret these, the general scheme of a URL is (and skipping the definitions of parts not germain to this—stuff in [] is optional, “*” means 0 or more, “+” is 1 or more, parenthesis denote groupings, etc):
> > > >
> ```
> <url> ::= <scheme> ':' [<net>] [<path>] ['?' <query>] ['#' <fragment>]
> <net> ::= '//' [<userinfo> '@'] <host> [ ':' <port> ]
> <path> ::= <segment> *( '/' <segment> )
> <segment> ::= *<character> *( ';' *<param> )
> <param> ::= *<character>
> <query> ::= *<character>
>
> ```
>
No structure is defined for <param> or <query> in the RFC (Request For Comments)s. By convention, the <query> portion is defined as:
> > > >
> ```
> <query> ::= <namevalue> *( '&' <namevalue> )
> <namevalue> ::= +<qchar> '=' *<qchar>
> <qchar> ::= <unreserved> | <escape>
> <unreserved> ::= <alpha> | <digit> | "$" | "-" | "_" | "." | "+" | "!"
> | "*" | "'" | "(" | ")" | ","
> <escape> ::= '%' <hexdigit> <hexdigit>
>
> ```
>
(there are also some restrictions on what can appear in a <segment> and <param>, but those are covered in the various RFCs, but note that the semicolon needs to be escaped in the query string, fancy that!)
The upshot is that you can have a URL of the form:
http://www.example.net/path;1/to;type=b/file.ext;v4.4?foo=a&bar=b (note)
(note—when giving a URL in an HTML (HyperText Markup Language) document, the '&' needs to be escaped to pass HTML validation)
where the parameters “;1”, “type=b” and “v4.4” apply to “path”, “to” and “file.ext” respectively (according to RFCs 2396 and 3986—as I read RFC-1808 it says that the <param> can only appear once, and that at the end of the <path> portion—but given that RFCs 2396 and 3986 are newer, I'll take those as correct).
Now, how this all relates to LID?
It's not pretty I'm afraid.
Apache [7] doesn't parse the path params correctly [as I found out today in playing around with this stuff –Sean]—or to be more precise, it doesn't parse them at all and passes them directly through to the filesystem. So while what you have is a decent workaround, it will probably only work for the perl CGI:: module; I can't say for any CGI (Common Gateway Interface) modules in other languages (and I know the one I wrote would have to be modified to support LID URLs).
I haven't had time to really look through the LID code to see all what it does, but as I have time, I'll do that. But feel free to keep asking questions—I'd like to help.
Basically, what they're trying to do is pass parameters as part of the URL, as well as pass parameters as part of a form (primarily using the POST method for certain actions). And what they're trying to do isn't so much illegal (in the “this type of stuff is not allowed in the protocol” sense) as it is unspecified. I created a simple test page of forms with various combinations of path parameters and query parameters using both GET and POST methods to see what information is passed through Apache to the simple script I was referencing. The results are mixed:
Table: Results of URL parameters with <FORM> parameters Method Script URL Paramters obtained from URL Paramters obtained from <FORM> ------------------------------ GET script.cgi;n1=v1;n2=v2 Requested URL script.cgi;n1=v1;n2=v2 was not found on this server GET script.cgi/;n1=v1;n2=v2 YES, in $PATH_INFO as “/;n1=v1;n2=v2” YES GET script.cgi?n1=v1;n2=v2 NO YES GET script.cgi/?n1=v1;n2=v2 NO YES GET script?n1=v1&n2=v2 NO YES POST script.cgi;n1=v2;n2=v2 Requested URL script.cgi;n1=v1;n2=v2 was not found on this server POST script.cgi/;n1=v1;n2=v2 YES, in $PATH_INFO as “/;n1=v1;n2=v2” YES POST script.cgi?n1=v1;n2=v2 YES, in $QUERY_STRING as “n1=v1;n2=v2” YES POST script.cgi/?n1=v1;n2=v2 YES, in $REQUEST_URI as “script.cgi/?n1=v1;n2=v2” YES POST script.cgi?n1=v1&n2=v2 YES YES ------------------------------ Method Script URL Paramters obtained from URL Paramters obtained from <FORM>
I'm beginning to think that the way LID works is about the only way for it to realistically work across webservers, seeing how path parameters are rarely used and that mixing parameters from the URL and <FORM> is unspecified for the most part.
Lovely.
[3] http://netmesh.info/jernst
[4] http://www.ietf.org/rfc/rfc1808.txt
[5] http://www.ietf.org/rfc/rfc2396.txt