Re: [Unbearable] Sec-Token-Binding header and Vary

Sure, I think it's reasonable to assume that most resources depending
on token bindings (or in response to a request with Sec-Token-Binding)
would be marked Cache-Control: private, or at least not have Vary:
Sec-Token-Binding, but even if that's the common case, spec-compliant
implementations still need to handle Vary: Sec-Token-Binding (rare as
it is) if that's something the spec allows.

On Mon, Apr 2, 2018 at 11:19 PM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> ...or say nothing.
>
> ...or observe that most resources that depend on token bindings will
> be marked Cache-Control: private.
>
> On Fri, Mar 30, 2018 at 8:20 AM, Nick Harper <nharper@google.com> wrote:
>> The Vary HTTP header specifies a list of headers whose values must
>> match for a resource to be served from the cache. HTTPSTB specifies
>> that a server MAY list Sec-Token-Binding in a Vary response header. I
>> think this behavior is silly, and we should disallow Sec-Token-Binding
>> in Vary.
>>
>> The reason why this is silly is that the Sec-Token-Binding header's
>> value is dependent on the underlying connection, and it will be
>> different for requests on different connections.
>>
>> Consider a request to example.com for resource foo, sent with the
>> Sec-Token-Binding header, that gets a response with "Vary:
>> Sec-Token-Binding", and a browser caches this response. The browser
>> then visits some page that includes resource foo, so it goes to see if
>> it can use it from cache. (Assume arguendo that all other caching
>> properties are such that if there weren't this Vary header the
>> response would be served from cache.) There are two options now:
>>
>> 1) The browser has no connection open to example.com. Any attempted
>> request for resource foo would have a different Sec-Token-Binding
>> header (because it cannot possibly match the header of the request
>> sent on a different connection), so the resource cannot be loaded from
>> cache because the Sec-token-Binding header can't match.
>> 2) The browser does have a connection open to example.com. Now, the
>> browser needs to check that if it were to make a request to
>> example.com for foo, whether the Sec-Token-Binding header it would
>> generate matches - if so it can serve the response from cache; if not,
>> it needs to continue sending the request on the network.
>>
>> A main reason for caching responses is so that they can be served
>> without ever going to the network. This now requires binding a request
>> to a particular network connection before evaluating whether it can be
>> served from the cache, which seems backwards and somewhere between
>> annoying and impossible to implement.
>>
>> I suggest changing the "MAY" to "MUST NOT": Under "Additionally, the
>> Sec-Token-Binding header field:" where it says "MAY be listed by a
>> server in a Vary response header field", change this to a "MUST NOT".
>>
>> _______________________________________________
>> Unbearable mailing list
>> Unbearable@ietf.org
>> https://www.ietf.org/mailman/listinfo/unbearable