Re: URI path starting with "//"

On Fri, Feb 1, 2013 at 5:37 PM, Julian Reschke <julian.reschke@gmx.de>wrote:

> On 2013-02-01 22:51, Phillip Hallam-Baker wrote:
>
>>
>>
>> On Fri, Feb 1, 2013 at 4:08 PM, Roy T. Fielding <fielding@gbiv.com
>> <mailto:fielding@gbiv.com>> wrote:
>>
>>     On Feb 1, 2013, at 12:34 PM, Julian Reschke wrote:
>>
>>      > On 2013-02-01 20:07, Bjoern Hoehrmann wrote:
>>      >> * Julian Reschke wrote:
>>      >>> On 2013-02-01 19:37, Zhong Yu wrote:
>>      >>>> If user clicks a URL http://example.com//abc, the browser
>>     should send
>>      >>>>
>>      >>>>      GET //abc HTTP/1.1
>>      >>>>      Host: example.com <http://example.com>
>>
>>      >>>>
>>      >>>> However the latest bis draft seems to forbid "origin-form" to
>>     start with "//"
>>      >>>> ...
>>      >>>
>>      >>> Is this a valid URI?
>>      >>
>>      >> http://www.websitedev.de/temp/**rfc3986-check.html.gz<http://www.websitedev.de/temp/rfc3986-check.html.gz>says yes.
>>     Per 3986:
>>      >>
>>      >>    URI           = scheme ":" hier-part [ "?" query ] [ "#"
>>     fragment ]
>>      >>    hier-part     = "//" authority path-abempty
>>      >>    ...
>>      >>    path-abempty  = *( "/" segment )
>>      >>    ...
>>      >>    segment       = *pchar
>>      >
>>      > Indeed. This appears to be an edge-case, but still...
>>
>>     Back in the really really early days of the Web, // would
>>     indicate a gateway (essentially, an open proxy).  TimBL said that
>>     the original idea was for many more layers than that, e.g.
>>
>>         ////first///second//third/path
>>
>>     as a form of routing.  Needless to say, that did not catch on.
>>
>>      > Roy, do you recall whether there's a reason why we would want to
>>     rule out a path starting with "//"?
>>
>>     No, it is an accident of the transition to new URI ABNF and
>>     should be raised as an issue.  There are several different ways to
>>     fix it, depending on how lenient we want to be with parsing.
>>
>>     ....Roy
>>
>>
>> There was another reason, it made it possible to use ftp and http URLs
>> interchangeably.
>>
>> I remember Robert Cailliau raising the issue at the leaving party for
>> TimBL from CERN and he admitted he didn't really have much of a good
>> answer.
>>
>>
>> I seem to recall that //domain/path was already in use at the time in
>> NFS and AFS like things and the web was following the same scheme.
>>
>> If you were using the Web browser prior to there being HTTP you would
>> have been using URIs of the form //afs.cern.ch/path
>> <http://afs.cern.ch/path>
>>
>>
>> So it would be natural to make them into:
>>
>> file://afs.cern.ch/path <http://afs.cern.ch/path>
>>
>>
>>
>> The main reason for keeping it at the time was that it provided a clear
>> visual distinction between a URL and a URN and the difference between
>> them was that a URL was an identifier that was relative to a DNS host
>> name and a URN was anything that was not a URL.
>>
>> I think that was actually a good idea. The three schemes that had DNS
>> domain names in them, file, http and ftp, all had the same
>> method://domain:port/stem pattern.
>> ...
>>
>
> Yes.
>
> But that doesn't seem to have anything to do with what we discuss here: a
> *path* starting with "//".
>
> Best regards, Julian
>

Ugh, hate that idea.

The reason for having the double slash on the host name was so that it was
possible to distinguish URI fragments that were relative to a scheme "//" ,
a host "/" or a directory (anything else).

Could be wrong but I would be very surprised if existing code didn't barf
up a path starting //. I certainly think it should do.


-- 
Website: http://hallambaker.com/