- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 07 Oct 2009 21:01:32 +0200
- To: Bjoern Hoehrmann <derhoermi@gmx.net>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
Bjoern Hoehrmann wrote: > * 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. Relative location headers per se aren't a problem; those that also include a fragment id are. BR, Julian
Received on Wednesday, 7 October 2009 19:02:13 UTC