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
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:46 UTC