- From: Kyle Rose <krose@krose.org>
- Date: Mon, 21 Sep 2015 08:22:48 -0400
- To: Yoav Nir <ynir.ietf@gmail.com>
- Cc: Mike Bishop <Michael.Bishop@microsoft.com>, Eric Rescorla <ekr@rtfm.com>, Stefan Eissing <stefan.eissing@greenbytes.de>, Ilari Liusvaara <ilari.liusvaara@elisanet.fi>, Mark Nottingham <mnot@mnot.net>, Henry Story <henry.story@co-operating.systems>, HTTP Working Group <ietf-http-wg@w3.org>
> Having the application layer stall doesn’t help. The client requests > resources A, B, and C. Resource B requires client authentication. By the > time the application stalls, waiting for the client authentication, > resources A and C may not have been noticed, or the requests may have been > serviced, with A and C in a buffer waiting to be encrypted, or the requests > may have been serviced and encrypted and on the way back to the client. A > and C may be received in the authenticated or the non-authenticated context. > Imagine, for example, that A is a bit of HTML that says “Hello, guest” in > the unauthenticated context, or “Hello, Mike” after authentication. You can > get the certificate picker and still see the “Hello, guest” on the page. > > What’s more, I think HTTP authentication has the same issue. If one request > gets processed and generates a 401 with WWW-Authenticate, other resources > may or may not have been serviced. You can fix this by carefully designing > the application so that you don’t load resources that are different based on > state at the same time as the authentication is going on. > > If multiple requests cause the server application to query the HTTP layer > for the client’s certificate, then all those requests will wait until the > client authentication has completed, just as they would have on a > non-multiplexed connection. Where multiplexing adds a new wrinkle is that, > under HTTP/1.1, those connections that didn’t require authentication would > proceed without interruption until they’re used for a protected request. How did this work in practice with HTTP/1.1, with browsers having multiple simultaneous connections open to the same server? If I had to guess, I'd say that the primary resource requiring authentication was typically the root HTML for a page, which would then of course stall every subsequent request for subresources without any specific support required in the client: neither multiplexing H2 nor simultaneous HTTP/1.1 connections would be subject to a race condition in this case, requests for the URLs from previously-loaded pages that vary on authentication notwithstanding. Otherwise, I'm guessing the user would have a sub-par UX (e.g., multiple certificate chooser dialogs). Kyle
Received on Monday, 21 September 2015 12:23:17 UTC