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

...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