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

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