- 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
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