- From: Slein, Judith A <JSlein@crt.xerox.com>
- Date: Mon, 21 Feb 2000 15:25:18 -0500
- To: "'Yaron Goland'" <yarong@Exchange.Microsoft.com>, "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
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