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

Re: Referer URI MUST NOT include a fragment

From: Adrien de Croy <adrien@qbik.com>
Date: Tue, 03 Mar 2009 09:47:10 +1300
Message-ID: <49AC45CE.1070804@qbik.com>
To: Vincent Murphy <vdm@vdm.ie>
CC: Albert Lunde <atlunde@panix.com>, ietf-http-wg@w3.org

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

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