Subject: RE: server parsing of URI path parameters

From: "Scott Lawrence" <[email-masked]>
Date: Mon, 3 Jan 2000 14:25:47 -0500

> From: Mark Nottingham [[email-masked]]
> To: [email-masked]
> Subject: server parsing of URI path parameters

> I've been looking at use of parameters on path segments of URIs,
> as discussed in RFC2396 (section 3.3).
> [...]
> With that in mind, a more HTTP-specific question: How should an
> origin server treat a request that includes parameters?

Any confusion here results from equating 'URL path' to 'file path';
it need not be.  Something in the server is responsible for
interpreting a path - doing so as a file path is just one
possibility.

> I suspect the answer depends on the purpose and uses of
> parameters, but I'm interested to get some views on this.

Exactly so.

--
Scott Lawrence      Director of R & D        <[email-masked]>
Agranat Systems   Embedded Web Technology   http://www.agranat.com/

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 03 Jan 2000 11:28:23 -0800

In message <[email-masked]>, 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