- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Wed, 07 Oct 2009 20:55:51 +0200
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
* Julian Reschke wrote:
>3) In the meantime, people have asked for an even less strict ABNF,
>allowing relative URIs (Issue 185:
><http://trac.tools.ietf.org/wg/httpbis/trac/ticket/185>)
>So for 3) the choices are:
>
>3a) Leave the behavior undefined (possible even not allowing it in the ABNF)
>
>3b) Document what makes sense (consistent with 2b), but point out that
>current implementations fail to do this
>
>3c) Document what they do, even though it doesn't make any sense.
>I'm currently leaning to 2b/3b, but I could be convinced to do 2a/3a
>instead. However, I don't see how I could do 2b/3c.
Well,
% tshark -T fields -e ip.src -e http.location -R "http.location and
not http.location contains """:"""" -r alexa50.pcap | wc -l
Gives 14 cases of relative Locations when loading the Alexa top 50 web
sites in http://cutycapt.sf.net/ at the moment. That's a lot less than
expected but then the sample is not very representative.
In the past I've found that simply choking on relative Location headers
is not really an option for non-browser applications, so I do think the
specification should say something about them, even if that's just a
note to the effect that implementers are likely to encounter them.
--
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Received on Wednesday, 7 October 2009 18:56:18 UTC