Re: ';' parameter in segments

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

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

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.

Seems like I discovered gold.

//Stefan


Am Donnerstag den, 28. Februar 2002, um 22:59, schrieb Al Gilman:

> At 07:27 AM 2002-02-28 , Stefan Eissing wrote:
>> RFC 2396 defines parameters in segments of hierarchical uris.
>
> RFC 2396 defines syntax allowing parameters in segments in 
> hierarchical paths in URIs.
>
> It does not define the parameters.
>
> Your service model must define the parameters.
>
> Have you considered putting your service parameters in a SOAP 
> envelope where you have a straightforward way to back them up with 
> a schema?
>
>> For my own uri class hierarchy I'm having a syntactically
>> correct implementation, passing all tests defined in 2396,
>> however I am at loss to how give users of my API access to
>> this information. This of courses touches on semantic issues
>> regarding these parameters:
>>
>> http://host/seg1/seg2;param
>> and
>> http://host/seg1/seg2?param
>>
>> are not equal, I assume. Can/should/must both refer to the
>> same resource?
>
> Can be same?  In the following sense:  Exercising them could 
> always have the same effect.
> Whether this makes the associated resources one and the same is 
> not so easy to get agreement on.
>
> Should both refer to the same resource?  Personal answer: no.  
> This answer probably gets pretty good support.
>
> Must both refer to the same resource?  Expected unanimous answer:  no.
>
> Shou>
>> How do
>>
>> http://host/seg1/seg2;param
>> and
>> http://host/seg1;param/seg2
>> and
>> http://host/seg1/seg2
>>
>> relate to each other (if at all)?
>>
>> Or, asking the other way around: What is the difference
>> between the following two uris:
>>
>> http://host/seg1;param/seg2
>> and
>> http://host/seg1%3bparam/seg2
>>
>
> There is a generic URI assertion about this last pair.
>
> The first of this pair generates two syntactically recognized 
> children from the path segment next after the host.  The second 
> generates one, containing an embedded reserved character.  The 
> second URI does not match the 'parameter' production in the 
> grammar and passes through un-divided.
>
> But beyond that it is up to you as the service offeror.  Don't 
> expect HTTP to tell you.
>
>> Is there a generic uri view on these examples or is it
>> merely an issue for HTTP (or whatever other hierarchical
>> scheme is used) to resolve?
>>
>
> It is for your service to resolve on receipt of a request.
>
> The path syntax allows you to bind protocol parameters by 
> positional association.  The searchpart syntax following the ? 
> allows you to bind protocol parameters by named association 
> (without regard to order).  The ;parameter syntax allows you to 
> elaborate on values, expecially of positionally associated 
> protocol parameters with qualifying expressions.
>
> Parameters appearing before the ? qualify the path segment that 
> they appear in (nominally).  Parameters appearing after the ? 
> qualify the whole URI.  But the functional effect is entirely at 
> the disposal of the service accessed, and the same effect can be 
> obtained in either syntax by determinedly obscure programming.  
> Without violating the URI syntax.
>
> But what all those protocol parameters mean is up to your service 
> offering.
>
> HTH
>
>
> Al
>> Best Regards, Stefan
>>
>

Received on Friday, 1 March 2002 09:12:06 UTC