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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:12 GMT