Re: Issue 43 (combining fragments)

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