- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Wed, 23 Sep 2015 20:41:24 -0700
- To: Amos Jeffries <squid3@treenet.co.nz>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 23 September 2015 at 19:02, Amos Jeffries <squid3@treenet.co.nz> wrote: > > Option 2 risks the same mess if the AUTH frame is defined end-to-end. > But a per-hop frame would work nicely as long as it is clear to server > implementers that intermediaries may be the source of the certificate. > Not some "user". This would naturally be hop-by-hop, by virtue of extensions being hop-by-hop and by virtue of the setting that enables it also being hop-by-hop. > An option 3 might be to use a SETTINGS instead of dedicated AUTH frame. > So that the per-hop nature is made extra clear. That would also be more > backward compatible with older h2 implementations and work in with > clearing dynamic compression contexts at the same time as authenticating. SETTINGS wouldn't allow the server to correlate the CertificateRequest with a specific request/response exchange. Also, while I think of it, we should probably forbid the use of this on server-initiated streams (i.e., with server push). That could cause problems.
Received on Thursday, 24 September 2015 03:41:55 UTC