Re: Referer URI MUST NOT include a fragment

Is there any case at all where currently a fragment ID hits the "wire"?  
I thought it was purely an in-browser feature, not really dependent on HTTP.


Vincent Murphy wrote:
> Thank you for your comment. Do you think the benefits outlined earlier
> outweigh these costs?
>
> I think this ranks way below a data spill as discussed earlier.
> Authentication checks based on string equality may fail because of a
> fragment identifier but they definitely won't succeed.
>
> It doesn't seem like a huge burden to implement string prefix checks
> instead. Its common knowledge that HTTP clients drop frag ids in
> requests so it wouldn't be a huge gap to expect people to understand a
> similar mechanism for Referer handling.
>
> I don't really care about making life easier for those who wish to
> restrict deep linking... :)
>
> 2009/3/1 Albert Lunde <atlunde@panix.com>:
>   
>> On Sun, Mar 01, 2009 at 12:19:57PM +0100, Julian Reschke wrote:
>>     
>>> Reminder: if we *did* want to relax this in HTTPbis, we will need to
>>> investigate whether relaxing the value range can break existing code.
>>>       
>> It's going to break existing web applications that do equality
>> tests on Referer for (weak) security, or to prevent deep linking
>> into web sites. Say, substring matches on hostname, won't be affected.
>> (All these things have to allow for the case that Referer
>> is not sent, but they can be brittle in other respects.)
>>
>> So the effect will be breakage of unspecified sites by the first browser
>> to adopt  it.
>>     
>
>   

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Monday, 2 March 2009 20:45:03 UTC