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