W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 2000

Re: server parsing of URI path parameters

From: Roy T. Fielding <fielding@kiwi.ICS.UCI.EDU>
Date: Mon, 03 Jan 2000 11:28:23 -0800
To: Mark Nottingham <mnot@pobox.com>
cc: http-wg@hplb.hpl.hp.com, mnot@akamai.com
Message-ID: <200001031128.aa04479@gremlin-relay.ics.uci.edu>
In message <19991230095914.A436@i.mnot.net>, Mark Nottingham writes:
>
>I've been looking at use of parameters on path segments of URIs, as
>discussed in RFC2396 (section 3.3).
>
>As I understand it, the original reason that parameters were used, and
>therefore the semicolon was a reserved character, is pre-HTTP/1.1 range
>specification.

Actually, no, they were introduced in RFC 1808 long before the
range hack.  Before that, I'd say they were most influenced by
the deisre to support versioning a la VMS.

>I'm not clear on their current use, and was a bit surprised
>to see 2396 say that each path segment could have its own parameters, so
>that you could get:
>  http://www.foo.com/bar;a=1;b=2/baz/bat.gif;g=5
>and so forth. If anyone could clear up the history here, I'd be grateful.

Think of it as an issue of precedence.  In almost all URL parsers,
the slash characters have precedence over any other character during
routine parsing of components.  The result is that the path is
separated into path segments before anything looks at the semicolons.

>With that in mind, a more HTTP-specific question:
>How should an origin server treat a request that includes parameters? Some
>trival testing suggests that current practice is to treat them as part of
>the path, so that an error is returned. Would it be better to have them
>ignore parameters that aren't understood? 

That is entirely dependent on the nature of the resource.  A server
can interpret its own namespace however it wants.

Cheers,

....Roy
Received on Monday, 3 January 2000 19:30:13 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:35 EDT