W3C home > Mailing lists > Public > uri@w3.org > March 2002

Re: ';' parameter in segments

From: Roy T. Fielding <fielding@apache.org>
Date: Fri, 1 Mar 2002 11:49:59 -0800
To: Stefan Eissing <stefan.eissing@greenbytes.de>
Cc: Al Gilman <asgilman@iamdigex.net>, uri@w3.org
Message-ID: <20020301114959.A1746@waka.wakasoft.com>
On Fri, Mar 01, 2002 at 03:11:46PM +0100, Stefan Eissing wrote:
> Thanks for the comments. If I understood you correctly, this
> means:
> 
> 1. Parameters are a syntactic construct in RFC 2396 which allows
>   extensions to path segments of hierarchical uris. There is no
>   predefined semantics to segment parameters.

Right.

> 2. Parameters are opaque to the "receiver" of an uri. For comparision,
>   and especially for resolving uris, parameters are treated as part
>   of the path segment.

It depends on the resolver.  "http" treats them as opaque.

> 3. An authority for the uri, what you call "service", is free to
>   use parameters however it likes in matching uris to resources and
>   vice versa. (follows from opacity)

It depends on the resolver.  "http" treats them as opaque.

> 4. Queries are different from parameters as:
>    - queries on base uris do not take part in resolving references
>      when the reference has a non-empty path.
>    - queries can be setup by a client (HTML forms)

It depends on the resolver.  "http" treats them as opaque.  Most HTTP
servers separate the query information from the path before determining
the handler for the resource identified by the host and path.

> Does anyone know of a server which makes use of parameters? Does
> for example Apache make any assumptions about parameters in path
> segments?

The Apache httpd by default does not make any distinction, but each Apache
module is capable of making a distinction on either a per-resource or
per-hierarchy basis.

> Background: I investigate parameters for possible use in WebDAV
> servers. A parameter could help solve the problem of adressing
> the source of a resource without introducing completely separate
> uri spaces for resources. Getting the source of an asp/jsp page
> has the problem that GET on http://somehost/welcome.asp is
> something completely different.
> Now GET on http://somehost/welcome.asp;source could retrieve the
> source code of asp without requiring extra headers in the request;
> nor introducing a new hierarchy in somehost;
> nor polluting the namespace of the top-level collection of
> somehost, as the resource welcome.asp%3bsource can still be there;
> nor colliding with query parameters to welcome.asp.

Yes, that is one of the reasons they exist.  However, there is no global
parameter meaning in URI space.  What that means is that each server has
to tell the client what URI(s) to use in order to access the source, which is
why the dav:source property exists.  Whether that URL is an added parameter
to the dynamic URI, a separate hierarchical space on the same server, or
a separate server altogether (as is common is staging environments) is
completely specifiable by the resource owner's server and thus doesn't
require any special convention in the URI syntax.

....Roy
Received on Friday, 1 March 2002 14:54:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:04 UTC