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

That doesn't require any more text than what is already in RFC 7234 though :)

On Wed, Apr 4, 2018 at 4:04 AM, Nick Harper <nharper@google.com> wrote:
> 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