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

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

From: Zhong Yu <zhong.j.yu@gmail.com>
Date: Tue, 4 Jun 2013 11:45:42 -0500
Message-ID: <CACuKZqHOMvcun9QV6zzeqVy8rWULjdL9ZU-49rmYt+qrC2tmkQ@mail.gmail.com>
To: "Roy T. Fielding" <fielding@gbiv.com>
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>
All right, everybody must be able to accept the URI. (Though privately
I'll never give that URI to anyone)

On Tue, Jun 4, 2013 at 11:00 AM, Roy T. Fielding <fielding@gbiv.com> wrote:
> 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
Received on Tuesday, 4 June 2013 16:46:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:13 UTC