W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2011

[whatwg] Feedback on Meta referrer

From: Adam Barth <w3c@adambarth.com>
Date: Sat, 31 Dec 2011 10:46:47 -0800
Message-ID: <CAJE5ia8FzOE3sahiLYdBfpuGjA8GDphn85qiZ1pad=DPRak1uw@mail.gmail.com>
On Sat, Dec 31, 2011 at 10:30 AM, David Bruant <bruant.d at gmail.com> wrote:
> Le 31/12/2011 19:11, Adam Barth a ?crit :
>> On Sat, Dec 31, 2011 at 9:44 AM, David Bruant <bruant.d at gmail.com> wrote:
>>> Hi,
>>>
>>> My feedback regards the current version of the wiki page [1].
>>>
>>> I'm curious about why a Referer header is always sent. Specifically for
>>> "never", an empty string is sent. Why not just not send the header at
>>> all?
>> Oh, the intent is for the header not to be sent for "never". ?Does
>> this happen in the WebKit implementation, or is this only a problem in
>> the spec?
> I noticed it on the spec. I haven't tested Webkit.
>
>>> Also, it seems to me that 2 different concerns are implicitely
>>> addressed: "when should the referer header be sent?" and "what should be
>>> sent in the referer header?" It could make sense to split up the
>>> proposal in 2 keywords.
>>> One controling when the header is sent:
>>> * never
>>> * same origin (send the referer header if the target URL and document
>>> URLs have the same origin)
>>> * defaut (secure referer & not secure fetched)
>>> * always
>>> * (...)
>>> another controling what is sent:
>>> * empty string (if there is really a use case for this)
>> I'm not there is a use case for the empty string.
>>
>>> * origin-only
>>> * fragmentless URL
>>> * (...)
>>>
>>> Current policies can be expressed as the combinaisons of the above:
>>> * "never" => default + empty string
>>> * "default" => default + fragmentless URL
>>> * "origin" => default + origin-only
>>> * "always" => always + fragmentless URL
>> The intended mapping is more like the following:
>>
>> * "never" => never + N/A
>> * "default" => default + fragmentless URL
>> * "origin" => always + origin-only
>> * "always" => always + fragmentless URL
> Ok. Thanks for the clarification.
>
>> Are there use cases for the other combinations?
>
> I think there could be a use case for same-origin+fragment-less URL
> which allows for "internal" tracking but not external tracking.

Yeah, that makes sense.  I'm not sure whether we need to have the
whole matrix though.  Thoughts on a good name?

>> For example, why
>> would someone want to use default+origin-only rather than
>> always+origin-only?
>
> I admit I don't know.
>
> I felt that there were two orthogonal concerns that were addressed and
> thought it would be interesting to point it out. If it turns out only a
> small number or combinaisons are relevant or have a use case, I have no
> problem with just standardizing these. But I think the proposal should
> make explicit that 2 concerns ("when" and "what") are addressed and that
> the choice is explicitely made to rule out some combinaisons.

Yeah, that makes sense to me.

Adam
Received on Saturday, 31 December 2011 10:46:47 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:38 UTC