- From: Phillip Hallam-Baker <hallam@gmail.com>
- Date: Fri, 1 Feb 2013 16:51:55 -0500
- 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>
- Message-ID: <CAMm+LwgDLmgA9qka0wk_J+jxqVHnPgNK9=FZZvnMdUBzyFPAiw@mail.gmail.com>
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 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 So it would be natural to make them into: file://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. 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 UTC