- From: David Bruant <bruant.d@gmail.com>
- Date: Sat, 31 Dec 2011 19:30:22 +0100
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.
> 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.
David
Received on Saturday, 31 December 2011 10:30:22 UTC