RE: Yaron.Redirect.S10

Comments interspersed in <js></js> tags.

-----Original Message-----
From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com]
Sent: Friday, February 11, 2000 2:54 AM
To: 'w3c-dist-auth@w3.org'
Subject: Yaron.Redirect.S10



Section 10 of the redirect spec requires that given a HTTP URL
http://foo/bar/blah <http://foo/bar/blah>  as the request-URI of a method if
http://foo/ <http://foo/>  or http://foo/bar/ <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.  

<js> I don't think it's quite that bad.  The server would probably first
check whether it has a mapping for the whole URI.  Only if it doesn't would
the server have to start checking subpaths.  So it's more complicated code,
but not a dramatic effect on efficiency. </js>

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/
<http://foo/>  on one server, http://foo/bar <http://foo/bar>  on another
server and http://foo/bar/blah <http://foo/bar/blah>  on a third server then
any requests to http://foo/bar/blah <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.) 

<js> Again, you would first attempt to resolve the URL in the usual way, and
only if that fails would you have to start checking sub-paths instead of
rejecting the request out of hand. </js> 

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
<http://foo/bar/blah>  when http://foo/bar <http://foo/bar>  is a redirect
resource to ftp://itsy/bitsy <ftp://itsy/bitsy> ? 

<js> We haven't really discussed this type of case, and you are right that
we have to address it somehow.  In the particular example you give, we could
just have the server follow the rules in section 10, and respond with a 302
and Location: ftp://itsy/bitsy/blah <ftp://itsy/bitsy/blah> . The client
would then have to figure out whether there is anything in ftp corresponding
to the method in its original request. </js> 

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

<js> I don't think this does raise the same issue.  All we are doing here is
making sure that you don't end up with a URL that has 2 consecutive slashes
in the middle somewhere. </js>

Received on Monday, 21 February 2000 15:25:25 UTC