- From: vanupam <notifications@github.com>
- Date: Tue, 03 Apr 2018 09:47:16 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Tuesday, 3 April 2018 16:47:41 UTC
vanupam commented on this pull request. > @@ -3237,6 +3566,31 @@ in addition to <a>HTTP fetch</a> above. nullity has already been checked. The <a lt=extract for=BodyInit>extracting</a> operation cannot throw as it was called for the same <a for=body>source</a> before. + <li><p>Let <var>useReferredTokenBinding</var> be the result of + <a for=header>parsing</a> `<a http-header><code>Include-Referred-Token-Binding-ID</code></a>` + in <var>actualResponse</var>'s <a for=response>header list</a>. + + <li><p>Set the <var>request</var>'s <a for=request>referred-token-binding origin</a> to null. + + <li><p>If <var>useReferredTokenBinding</var> is `<code>true</code>` Per the TOKBIND-HTTPS spec, this header has a single valid value (not a list), so servers must not emit multiple headers (per HTTP spec). As currently described, multiple headers would be treated as an invalid value. Reasonable? @nharper , here useReferredTokenBinding causes the referred-token-binding origin to be set for the upcoming redirect request only if the request is currently using token binding. Need more clarification? -- 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_r178889919
Received on Tuesday, 3 April 2018 16:47:41 UTC