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

Re: URI path starting with "//"

From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Fri, 1 Feb 2013 16:51:55 -0500
Message-ID: <CAMm+LwgDLmgA9qka0wk_J+jxqVHnPgNK9=FZZvnMdUBzyFPAiw@mail.gmail.com>
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: Julian Reschke <julian.reschke@gmx.de>, Bjoern Hoehrmann <derhoermi@gmx.net>, Zhong Yu <zhong.j.yu@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Fri, Feb 1, 2013 at 4:08 PM, Roy T. Fielding <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
> >>>>
> >>>> 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

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

So it would be natural to make them into:


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.

On Fri, Feb 1, 2013 at 4:26 PM, Tim Bray <tbray@textuality.com> wrote:

> Itís also potentially a source of confusion - in the process of
> switching some stuff over from http to https, I had occasion to use
> lots of URI references of the form "//server/path", which turn out to
> be quite useful, and are an entirely different thing from this
> two-stroke idiom.  -T

I am not sure if that means you like //server/path or not.

I think the // part actually helps here. It would also help if we were
doing a coap to http transition.

Website: http://hallambaker.com/
Received on Friday, 1 February 2013 21:52:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 1 February 2013 21:52:37 GMT