Seeking wisdom on URI path parameters.

JanC usenet_spam at janc.invalid
Fri May 30 22:47:04 EDT 2003


Steven Taschuk <staschuk at telusplanet.net> schreef:

> Quoth JanC:
>   [...]
>> In 3.3.: "Each path segment may include a sequence of parameters,
>> indicated by the semicolon ';' character."
>> --> note the use of "include".
>> 
>> In 5. it says: "Within a relative-path reference, the complete path
>> segments '.' and '..' have special meanings: 'the current hierarchy
>> level' and 'the level above this hierarchy level', respectively."
>> --> _complete_ segment must be '.' or '..'
>> 
>> So I would say:
>> http://localhost/dir;im_ignoring=this/subdir;and=this/.;param=value/fo
>> o.html (whatever that may mean to the web server...)
>> 
>> And that's also exactly what the example algorithm does.
> 
> Indeed.  But as the OP pointed out, in section 3.3 it is written
> that "parameters are not significant to the parsing of relative
> references".  With the above behaviour -- which I agree is a
> reasonable reading of the RFC -- they are significant, since they
> make the difference between '.' (which is treated specially) and
> '.;param=value' (which is not).  (They're also significant the
> other way, of course.)

You could read "they are not significant" as "it's not significant whether 
parameters are included or not" or "their existence is not significant".

Remember parameters are _included_ in the path segment, not appended to 
them.  That's also how the sort-of-BNF declares them.


> I read "complete" in "complete segment" as possibly intended to
> emphasize that, e.g., '.foo' and '..bar' are not special as path
> components. 

I read "complete segment" as "complete segment", that is _including_ the 
parameters.

A URL "path" has nothing to do with a filesystem "path" unless the program 
that translates the URL to a resource is programmed to do that.
(E.g. most web servers map de HTTP URL path directly to a fysical 
filesystem path, but that's only a choice the authors made to make it easy 
to use.)


[snip examples]
> It would have been nice if the appendix had included an example
> such as ".;param=value/whatever" to make this point unambiguous.

Indeed, that would be really really nice...  :)


Maybe the OP should ask the "pros" at www-talk at w3.org
<http://www.w3.org/Addressing/>

-- 
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9




More information about the Python-list mailing list