- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Tue, 4 Jun 2013 09:00:22 -0700
- To: Zhong Yu <zhong.j.yu@gmail.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>
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