W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2009

Re: Issue 43 (combining fragments)

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 07 Oct 2009 21:01:32 +0200
Message-ID: <4ACCE58C.2050208@gmx.de>
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

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