Re: HTTP URI in the form of "http://example.com?query"

"Roy T. Fielding" <fielding@gbiv.com> Tue, 04 June 2013 17:34 UTC

Resent-Date: Tue, 04 Jun 2013 16:01:23 +0000
Resent-Message-Id: <E1Ujtfn-0005Kx-Dr@frink.w3.org>
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="iso-8859-1"
From: "Roy T. Fielding" <fielding@gbiv.com>
In-Reply-To: <CACuKZqEqTHa0uy9hjzKT9ctm3SZ9q2ySe2brrGy3v82HKVxfvQ@mail.gmail.com>
Date: Tue, 04 Jun 2013 09:00:22 -0700
Cc: Daniel Stenberg <daniel@haxx.se>, Julian Reschke <julian.reschke@gmx.de>, Roberto Peon <grmocg@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C54A3377-A891-422D-BDFB-E14DF2E4F7A3@gbiv.com>
References: <CACuKZqFvFo2ztDBZwMVtSE54rvHthyJJc-8X-yFq=CSVMy9GXw@mail.gmail.com> <51AD8EC1.4010608@gmx.de> <CAP+FsNd3mWAtQ_Fn_Kvtx28300SO761fEZBhnm9NrHv_WQ2BjQ@mail.gmail.com> <51AD9A87.9020403@gmx.de> <CAP+FsNe9oZQPxS-8rhz=MYiLj8aceKFTCJow4wrRnXDrrgdzww@mail.gmail.com> <51AD9F87.5050603@gmx.de> <alpine.DEB.2.00.1306041215460.32021@tvnag.unkk.fr> <CACuKZqEqTHa0uy9hjzKT9ctm3SZ9q2ySe2brrGy3v82HKVxfvQ@mail.gmail.com>
To: Zhong Yu <zhong.j.yu@gmail.com>
Received-SPF: none client-ip=208.97.132.81; envelope-from=fielding@gbiv.com; helo=homiemail-a30.g.dreamhost.com
Subject: Re: HTTP URI in the form of "http://example.com?query"
Archived-At: <http://www.w3.org/mid/C54A3377-A891-422D-BDFB-E14DF2E4F7A3@gbiv.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

No, the URI is correctly handled by all relevant implementations.
There is no opportunity for error handling while parsing a URI,
so it is useless to create corner cases where a parser doesn't
know what string is associated with which component.

The ABNF in 2616 was known to be buggy since before it was even
published, so I have no interest in considering it further.

The definition of http URIs in practice is that they accept any
string, parse according to the regex in 3986, and fix such things
as an empty path as part of the request handling.  The only part
of HTTP that needs to consider this case is the creation of a
request-target, and we already have that requirement in the spec.

....Roy

On Jun 4, 2013, at 8:38 AM, Zhong Yu wrote:

> How about we add some cautionary notes on this kind of URIs:
> 1. consumers must accept them
> 2. producers should not produce them
> 3. a middle man should add the slash before forwarding it to others.
> 
> Zhong Yu
> 
> 
> On Tue, Jun 4, 2013 at 5:19 AM, Daniel Stenberg <daniel@haxx.se> wrote:
>> On Tue, 4 Jun 2013, Julian Reschke wrote:
>> 
>>> Yes, but what's the exact breakage except for one component not processing
>>> that edge case? It's an edge case after all?
>> 
>> 
>> I only recently got a bug report for curl as when we got an input such as
>> that and passed it to a particular (unspecified) proxy it would reject it as
>> illegal.
>> 
>> Thus curl nowadays will insert a slash before passing on the URL to a proxy.
>> 
>> --
>> 
>> / daniel.haxx.se
>

HTTP URI in the form of "http://example.com?query" Zhong Yu
Re: HTTP URI in the form of "http://example.com?q… Julian Reschke
Re: HTTP URI in the form of "http://example.com?q… Roberto Peon
Re: HTTP URI in the form of "http://example.com?q… Julian Reschke
Re: HTTP URI in the form of "http://example.com?q… Roberto Peon
Re: HTTP URI in the form of "http://example.com?q… Julian Reschke
Re: HTTP URI in the form of "http://example.com?q… Bjoern Hoehrmann
Re: HTTP URI in the form of "http://example.com?q… Daniel Stenberg
Re: HTTP URI in the form of "http://example.com?q… Zhong Yu
Re: HTTP URI in the form of "http://example.com?q… Roy T. Fielding
Re: HTTP URI in the form of "http://example.com?q… Zhong Yu
Re: HTTP URI in the form of "http://example.com?q… Willy Tarreau
Re: HTTP URI in the form of "http://example.com?q… Zhong Yu