Subject: RE: Collections and Request-URIs

From: "Clemm, Geoff" <[email-masked]>
Date: Tue, 18 Jun 2002 07:49:17 -0400

I agree with Julian (i.e. that trailing slashes are allowed by
the syntax), but I also have argued vigorously that the RFC-2518
"guidance" is incorrect, and the next revision of RFC-2518 should
simply state "a URI with a trailing slash SHOULD identify the
same resource as the URI with the trailing slash removed".

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]
Sent: Tuesday, June 18, 2002 2:17 AM
To: Jim Luther; [email-masked]
Subject: RE: Collections and Request-URIs

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jim Luther
> Sent: Tuesday, June 18, 2002 1:46 AM
> To: [email-masked]
> Subject: Collections and Request-URIs
>
>
>
> RFC 2518, section 5.2 says:
>
> "There is a standing convention that when a collection is referred to by
> its name without a trailing slash, the trailing slash is automatically
> appended.  Due to this, a resource may accept a URI without a
> trailing "/" to point to a collection. In this case it SHOULD return a
> content-location header in the response pointing to the URI ending with
> the "/". For example, if a client invokes a method on
> http://foo.bar/blah (no trailing slash), the resource
> http://foo.bar/blah/ (trailing slash) may respond as if the operation
> were invoked on it, and should return a content-location header with
> http://foo.bar/blah/ in it.  In general clients SHOULD use the "/" form
> of collection names."
>
> It looks to me like the "standing convention" doesn't match the BNF. RFC
> 2616, section 5.1.2 gives this rule for the Request-URI in the
> Request-Line:
>
> 	Request-URI 	= "*" | absoluteURI | abs_path | authority
>
> and RFC 2396, section 3 gives these rules for abs_path and path_segments:
>
> 	abs_path      = "/"  path_segments
> 	path_segments = segment *( "/" segment )
>
> So by my reading, abs_path should not have a trailing slash. Did I miss
> something? If not, I think the WebDAV spec should say that servers MUST
> handle Request-URIs to collections without the trail slash.

However:

segment       = *pchar *( ";" param )
param         = *pchar

pchar         = unreserved | escaped |
                ":" | "@" | "&" | "=" | "+" | "$" | ","

([1]) and

"The second convention is a BNF-like grammar, used to define the formal URI
syntax. The grammar is that of [RFC822], except that "|" is used to
designate alternatives. Briefly, rules are separated from definitions by an
equal "=", indentation is used to continue a rule definition over more than
one line, literals are quoted with "", parentheses "(" and ")" are used to
group elements, optional elements are enclosed in "[" and "]" brackets, and
elements may be preceded with <n>* to designate n or more repetitions of the
following element; n defaults to 0."

([2]). So it seems that "segment" may be empty.

Julian

[1] <http://greenbytes.de/tech/webdav/rfc2396.html#rfc.section.3.3>
[2] <http://greenbytes.de/tech/webdav/rfc2396.html#rfc.section.1.6>

---

From: Jim Luther <[email-masked]>
Date: Tue, 18 Jun 2002 07:45:47 -0700

Thanks for the clarification, Julian.

> same resource as the URI with the trailing slash removed".

I'd argue that it must state "a URI with a trailing slash MUST identify 
the same resource as the URI with the trailing slash removed". Using 
SHOULD would leave it up to the server to do whatever, and would make 
the rules for a PROFIND Request-Line different than the rules in RFC 
2616 for Request-Line. (In general, I dislike seeing SHOULD and MAY in 
specifications when the subject of particular rule isn't optional.)

- Jim

---

From: Dan Brotsky <[email-masked]>
Date: Tue, 18 Jun 2002 09:06:08 -0700

> same resource as the URI with the trailing slash removed".

But do you also want this to be the case for non-collection resources?  
Perhaps you mean "if a URI that ends in a trailing slash identifies a 
DAV-compliant collection resource, then the same URI with the trailing 
slash removed SHOULD identify the same resource."  I would actually go 
for MUST in that case, although such a change would break some existing 
servers.

     dan

---

From: Stefan Eissing <[email-masked]>
Date: Tue, 18 Jun 2002 19:04:02 +0200

Am Dienstag den, 18. Juni 2002, um 18:06, schrieb Dan Brotsky:

> But do you also want this to be the case for non-collection 
> resources?  Perhaps you mean "if a URI that ends in a trailing 
> slash identifies a DAV-compliant collection resource, then the 
> same URI with the trailing slash removed SHOULD identify the same 
> resource."  I would actually go for MUST in that case, although 
> such a change would break some existing servers.
>
>     dan

I think the current approach in RFC 2518 works just fine, e.g.
to indicate in the Content-Location that this entity is really
located somewhere else.

It worked until Apache 2.0 and I do not see any benefit
in the new 301 for PROPFIND behaviour. Lack of deep insight
on my part most likely.

But even if /a and /a/ is the same from WebDAV point of view,
there are a lot of common use cases where GET on /a/b will
return 301/302 to /a/b/ no matter what WebDAV has to say about it.
The good old index.html trick...

//Stefan