W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: URI path starting with "//"

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 01 Feb 2013 23:37:51 +0100
Message-ID: <510C43BF.5030708@gmx.de>
To: Phillip Hallam-Baker <hallam@gmail.com>
CC: "Roy T. Fielding" <fielding@gbiv.com>, Bjoern Hoehrmann <derhoermi@gmx.net>, Zhong Yu <zhong.j.yu@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
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 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
Received on Friday, 1 February 2013 22:38:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 1 February 2013 22:38:24 GMT