RE: Yaron.Redirect.S10

Point #1 - I agree that we need a redirect resource with the full path
behavior. However, we also need a type of redirect resource that does NOT
have the path behavior. In other words, I am asking that we have two types
of redirect resource.

Point #2 - Your ACL analysis is inconsistent with at least Windows design.
In Windows when you set an ACL on a collection inheritance is done at the
time the ACL is set. This means that when doing a look up you only need to
check the individual file, not its parents, since any settings from the
parents that would affect the child would already have been propagated. This
behavior is typical for systems with high read rates. They put the onus on
non-read commands to leave the system in such a state as reads will be very
fast. This usually means that non-read commands are responsible for updating
the state of all resources such that when a read is executed it can be
implemented without having to refer to any resource but the target. This, of
course, slows down the performance of non-read commands but in most systems
there are many more reads than just about any command but write and write is
usually so super localized in its effect that this isn't a problem.

> -----Original Message-----
> From: Clemm, Geoff [mailto:gclemm@Rational.Com]
> Sent: Thu, February 24, 2000 8:32 PM
> To: w3c-dist-auth@w3.org
> Subject: RE: Yaron.Redirect.S10
> 
> 
> 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 Friday, 25 February 2000 02:02:19 UTC