Re: Referer URI MUST NOT include a fragment

2009/2/26 Larry Masinter <masinter@adobe.com>:
> I think the idea of allowing fragment identifiers in
> Referer is interesting, and I'm not sure what it would
> break. It couldn't be mandated.

A SHOULD would be good enough because it would allow user agent
implementers to implement without contradicting HTTPbis. That would
make it much easier to advocate for this with incumbent browser
vendors.

> I think the privacy
> security concerns about Referer remain, and perhaps
> the restriction was just a way of minimizing the
> exposure?

If the user information in web pages is based on the cookie/session;
an agent accessing the Referer resource wouldn't see that user
information. I believe this to be the case with most web pages.

I don't think the Referer would expose much information over and above
that which is already gathered in session logs using cookies.

> The important limits on Referer in RFC 2616
> are in the "Security Considerations" section
> http://tools.ietf.org/html/rfc2616#section-15.1.2

Thanks for the reference; I hadn't read that.

Perhaps security concerns like this could be addressed by having a
attribute on <a>, e.g. referer="none", which allows the author to
suppress the Referer header altogether. The default behaviour would be
to include a Referer header with the fragment id.

Received on Saturday, 28 February 2009 22:01:52 UTC