- From: Mike West <notifications@github.com>
- Date: Fri, 05 May 2017 02:45:29 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fetch/pull/325/review/36468871@github.com>
mikewest commented on this pull request. > + <dfn export id=concept-token-binding-key-parameters>token-binding key parameters</dfn>) in a + <code>token_binding</code> Client Hello Extension, as described in + <a href="https://tools.ietf.org/html/draft-ietf-tokbind-negotiation#section-2">section 2</a> + of the Token Binding Negotiation spec [[!TOKBIND-NEGOTIATION]]. + If Token Binding Negotiation succeeds, indicating client-server agreement on protocol version + and <a for=/>token-binding key parameters</a>, update metadata for the TLS connection with the + results of the negotiation. + + <p class="note no-backref"> + The user agent will use <a for=/>Token Binding</a> for any <a for=/>request</a> sent over + a TLS connection for which Token Binding Negotiation was successful. + Since <a for=/>Token Binding</a> is used only when <var>credentials</var> is true, such a + connection will not be pooled with connections that have <var>credentials</var> is + false. Also, <a for=/>Token Binding</a> is compatible with connection reuse - HTTP/2 requests to + different origin servers coalesced over the same connection will use different + <a for=/>token-binding key</a>s if needed. It's totally possible for the browser to decide not to send cookies even though the `credentials` flag is set. I guess you can think of the flag as "Might credentials ever be sent over this connection?" in this case. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/pull/325#discussion_r114962758
Received on Friday, 5 May 2017 09:46:05 UTC