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: Roy T. Fielding <fielding@gbiv.com>
Date: Tue, 4 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>
Message-Id: <C54A3377-A891-422D-BDFB-E14DF2E4F7A3@gbiv.com>
To: Zhong Yu <zhong.j.yu@gmail.com>
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:01:10 UTC

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