Yaron.Redirect.S10

Section 10 of the redirect spec requires that given a HTTP URL
http://foo/bar/blah as the request-URI of a method if http://foo/ or
http://foo/bar/ are redirect resources then the request must be redirected
to the locations specified by those redirect resources with the remaining
part of the request-URI appended to the redirection location. This means
that when a HTTP URL is submitted the server must examine each segment of
the URL and determine if any of those segments point to a redirect resource.
This means that every time a URL is submitted a minimum of N lookups must
occur where N equals the number of segments of the URL. This has a
devastating effect on efficiency. In the current HTTP system one can
implement a HTTP URL to resource mapping mechanism in two steps.

Step 1 - Look up the name and get back the internal pointer to the resource.
Step 2 - Use internal point to submit method to resource.

Section 10 changes this, for all HTTP URL namespaces that have redirect
support, to be:

For (segment 1 to segment N) {
   If (typeof(segment) == redirect) {
      Issue 300
   }
}
Segment(Method)

The section 10 requirement would be the first time we ever required that the
processing of a URL to resource mapping was dependent on the state of any
resource other than the target. This seems like a really bad precedent to
set as it significantly increases the complexity and cost of handling HTTP.

In addition this requirement makes it very difficult and extremely
inefficient to distribute one's namespace. If one wants to put http://foo/
on one server, http://foo/bar on another server and http://foo/bar/blah on a
third server then any requests to http://foo/bar/blah MUST be sent to the
two others servers in order to figure out if any of them is a redirect
resources. This is an enormous burden to put on implementers wishing to
distribute their namespace. (Note that in a WebDAV consistent namespace
there would be a similar requirement but it would only apply to the
immediate parent and so at most one other system, not N other systems as the
redirect draft requires.)

This all having been said, the motive behind introducing the section 10
behavior is clear and reasonable. The desire is to enable redirect resources
to create the same experience for the end user as a bind resource. However
here we run into an issue that is peculiar to HTTP. HTTP's resource
namespace is not consistent. Even the WebDAV namespace, if non-WebDAV
resources are included, is not required to be consistent. Namespace
consistency brings with it too high a cost in terms of coordination and
complexity to be mandatory.

Therefore, at minimum, we require a type of redirect resource that does not
have the section 10 behavior. This resource would expose the behavior we see
today in various HTTP servers that allow their users to create 300
resources. Therefore I move that a type of redirect resource be specified in
the redirect spec that does not have section 10 behavior.

That having been said I am sympathetic to the desire to have the section 10
rules. They certainly replicate the behavior seen today in many systems. As
such I will not object to the inclusion of a redirect resource with section
10 behavior in the redirect spec. However I do move that the authors must
address the issue of what happens when the redirection location isn't a HTTP
URL. How do we handle a request for http://foo/bar/blah when http://foo/bar
is a redirect resource to ftp://itsy/bitsy?

Paragraph 3 of section 10 reads:

Note: If the DAV:reftarget property ends with a "/" and the remainder of 
the Request-URI is non-empty (and therefore must begin with a "/"), the 
final "/" in the DAV:reftarget property is dropped before the remainder 
of the Request-URI is appended.

This behavior is in contradiction to both RFC 2518 and RFC 2616. Resources
that end with a "/" are currently considered different resources from those
that do not end with a "/". This is exactly the same issue brought up in
Yaron.NoSlash
(http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0069.html) and
I would love to see option 2 as listed there adopted. Failing that the
authors must adopt option 1 and change the draft. Either way, I move that
the authors must address this issue based on the requirements placed in
Yaron.NoSlash.