Subject: URI path starting with "//"

From: Zhong Yu <[email-masked]>
Date: Fri, 1 Feb 2013 12:37:38 -0600

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 "//"

http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-21#section-5.3

    origin-form    = path-absolute [ "?" query ]

http://tools.ietf.org/html/rfc3986#section-3.3

    path-absolute   ; begins with "/" but not "//"

I couldn't find anything in RFC 3986 that accurately describe the path
part that we really want, which should be

    path-xxx = "/" *( "/" / pchar )

HTTP probably need to define this term. It'll also help people to
finally refer to this thingy with a proper name.

Zhong Yu

---

From: Julian Reschke <[email-masked]>
Date: Fri, 01 Feb 2013 19:57:33 +0100

On 2013-02-01 19:37, Zhong Yu wrote:
> ...

Is this a valid URI?

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 01 Feb 2013 20:07:57 +0100

>> However the latest bis draft seems to forbid "origin-form" to start with "//"

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
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Fri, 01 Feb 2013 21:34:59 +0100

>     path-abempty  = *( "/" segment )

Indeed. This appears to be an edge-case, but still...

Roy, do you recall whether there's a reason why we would want to rule 
out a path starting with "//"?

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 1 Feb 2013 13:08:25 -0800

> 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

---

From: Tim Bray <[email-masked]>
Date: Fri, 1 Feb 2013 13:26:47 -0800

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 1 Feb 2013 16:51:55 -0500

> fix it, depending on how lenient we want to be with parsing.

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.

> be quite useful, and are an entirely different thing from this

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/

---

From: Julian Reschke <[email-masked]>
Date: Fri, 01 Feb 2013 23:37:51 +0100

On 2013-02-01 22:51, Phillip Hallam-Baker wrote:
>
>
> On Fri, Feb 1, 2013 at 4:08 PM, Roy T. Fielding <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>      >>>>      Host: example.com <http://example.com>
>      >>>>
> 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>
>
> file://afs.cern.ch/path <http://afs.cern.ch/path>
>
>
> 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.
>

Yes.

But that doesn't seem to have anything to do with what we discuss here: 
a *path* starting with "//".

Best regards, Julian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 1 Feb 2013 17:46:42 -0500

On Fri, Feb 1, 2013 at 5:37 PM, Julian Reschke <[email-masked]>wrote:

>>      >> http://www.websitedev.de/temp/**rfc3986-check.html.gz<http://www.websitedev.de/temp/rfc3986-check.html.gz>says yes.
>>     Per 3986:
>>      >>
> 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.

---

From: Eliezer Croitoru <[email-masked]>
Date: Sat, 02 Feb 2013 00:49:12 +0200

> a *path* starting with "//".
I have a question:
What a *path* starting with "//" effect is?
can it harm something?
The only thing for that is maybe for a split method\function that 
recognizes a path by the first single "/".

??

-- 
Eliezer Croitoru

---

From: Zhong Yu <[email-masked]>
Date: Fri, 1 Feb 2013 17:47:50 -0600

On Fri, Feb 1, 2013 at 4:46 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> 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.

I've heard web apps that use "//" paths for their "special" urls like
http://example.com//admin, and my experiments with it didn't show any
problems. (Though, one cannot write in html <a href="//path">, it
means something else.)

Zhong Yu

---

From: Nico Williams <[email-masked]>
Date: Fri, 1 Feb 2013 18:07:38 -0600

> What a *path* starting with "//" effect is?

Possibly.  POSIX allows // to be special (because some OSes used to
treat that differently than just an absolute path).  You might get
special handling of the first component (it's a server name!) or
whatever.  But nowadays POSIXy systems all (I think) treat that the
same as just one /.  On Windows \\ -> UNC, and / is often mapped to
\\, so yes, it might cause harm. but it depends in part on what the
web server does with such a path -- it needn't be a filesystem path,
after all, or it might be taken to be relative to another path (doc
root), in which case // means nothing special on POSIXy systems (POSIX
doesn't allow special meaning for // except at the front of a path).
So.... in conclusion, I think // is mostly harmless.

Nico
--

---

From: Julian Reschke <[email-masked]>
Date: Sat, 02 Feb 2013 10:35:58 +0100

> fix it, depending on how lenient we want to be with parsing.

Now <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/431>.

---

From: Karl Dubost <[email-masked]>
Date: Mon, 4 Feb 2013 16:47:57 -0500

Another benefit in Web projects specifically between testing environment and production to be able to not have to take care of http or https

https://example.org/
http://example.org/

Instead you would just write 

//example.org

See for example http://paulirish.com/2010/the-protocol-relative-url/

-- 
Karl Dubost, a Web opener to hire
http://www.la-grange.net/karl/

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 5 Feb 2013 12:07:49 +1100

Quickly tested the URI <http://www.mnot.net//index.html> on Safari, Chrome and Firefox (all OSX); all of them emitted the bits on the wire as anticipated (i.e.., GET //index.html). Squid didn't rewrite it, Apache happily served it, internally rewriting to /index.html (which is its choice).

Is this confusing for folks who are authoring links? Absolutely, considering that these will point to different resources:

http://example.com//foo
//foo <-- assuming base URI is http://example.com/

That said, we appear to have interop, so I think we need to change it back, so as to allow it.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Fri, 08 Feb 2013 18:05:37 +0100

> finally refer to this thingy with a proper name.

We have

with

   path-absolute = "/" [ segment-nz *( "/" segment ) ] ; 
<http://greenbytes.de/tech/webdav/rfc3986.html#path>

Using

   origin-form  = "/" [ segment *( "/" segment ) ] [ "?" query ]

...seems to be the minimal change (or can we simplify that production 
further without losing readability?)

Best regards, Julian

---

From: Zhong Yu <[email-masked]>
Date: Fri, 8 Feb 2013 16:48:53 -0600

>   origin-form  = "/" [ segment *( "/" segment ) ] [ "?" query ]

This should work too

    origin-form  = 1*( "/" segment )  [ "?" query ]

---

From: Julian Reschke <[email-masked]>
Date: Sun, 10 Feb 2013 16:45:12 +0100

>> further without losing readability?)

Proposed patch: 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/431/431.diff>

...I ended up defining a new production, for the absolute path, because 
other parts of the spec refer to it in prose.

Feedback appreciated,

Julian

---

From: Zhong Yu <[email-masked]>
Date: Sun, 10 Feb 2013 10:23:43 -0600

> other parts of the spec refer to it in prose.

I like the term "absolute-path".

I think

    absolute-path = 1*( "/" segment )

will make the intention more obviously.

---

From: Julian Reschke <[email-masked]>
Date: Sun, 10 Feb 2013 18:16:21 +0100

> will make the intention more obviously.

Indeed!

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 11 Feb 2013 15:14:35 +0100

> will make the intention more obviously.

...incorporated with 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2181>.

Best regards, Julian