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 <>:
>> 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 -

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