Re: Referer URI MUST NOT include a fragment

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.

Received on Monday, 2 March 2009 20:25:10 UTC