W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2000

RE: Yaron.Redirect.S10

From: Clemm, Geoff <gclemm@Rational.Com>
Date: Thu, 24 Feb 2000 23:32:07 -0500
Message-ID: <65B141FB11CCD211825700A0C9D609BC0205B023@chef.lex.rational.com>
To: w3c-dist-auth@w3.org
I disagree that an O(N) cost on error should cause us to eliminate
behavior that is both useful and expected by clients (at least, by
clients used to file-system implementations of redirect references,
such as sym-links on Unix).

First, the "N" here is very small (5, 10, not 1000).  Second, it is
likely that servers will have to do this anyway when ACL's are
introduced (you will have to check if you have a READ ACL to each
collection in the path).  And finally, the cost of doing this lookup
is likely to have been so optimized by the underlying system 
that the total cost will be minimal in any case.

Cheers,
Geoff

> -----Original Message-----
> From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com]
> Sent: Thursday, February 24, 2000 1:53 AM
> To: 'Slein, Judith A'; w3c-dist-auth@w3.org; 'yaron@goland.org'
> Subject: RE: Yaron.Redirect.S10
> 
> 
> The main contention in Judy's comments is that implementing 
> the section 10
> rules isn't that bad because you can always do a hash look up 
> first on a
> name and if you don't get a hit then you can begin the 
> segment by segment
> walk. I disagree with the assessment that the cost is 
> trivial. Every single
> time a URL mis-hits the server will be forced to spend time 
> walking all of
> its segments in order to figure out if the URL may point to a redirect
> resource. The cost of processing a bogus URL has gone from 
> O(1) to O(N).
> That makes it very easy to use bogus URLs as a denial of 
> service attack.
> 
> This all begs the issue, BTW, of the fact that the design means that
> processing URLs correctly pointing to redirect resources will 
> cost O(N).
> 
> All this having been said, as I indicate below, I understand 
> why the authors
> want to make redirect resources behave as they have specified and I am
> sympathetic to their goals. I think the best compromise is 
> for us to create
> two types of redirect resources (created by two different 
> methods). One type
> is a simple HTTP redirect resource. No fancy namespace rules. 
> No section 10
> behavior. All it does is blindly return a 302 to a certain 
> value, that is
> it. It doesn't matter if it is in a WebDAV namespace or not. 
> It just returns
> a 302. Then we create a complex HTTP redirect resource with section 10
> behavior. People who want to take on the O(N) costs 
> associated with it are
> free to do so. But let's not penalize WebDAV implementers who 
> just want a
> simple 302 by forcing a O(N) solution on them.
> 
> As for my comment regarding paragraph 3 of section 10, I 
> agree with Judy's
> comment that my analysis is flawed and so remove my comment.
> 
> 			Yaron
> 
> 
> > -----Original Message-----
> > From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> > Sent: Mon, February 21, 2000 12:25 PM
> > To: Yaron Goland; w3c-dist-auth@w3.org
> > Subject: 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 Thursday, 24 February 2000 23:44:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:54 GMT