On Sep 23, 2015 1:55 AM, "Stefan Eissing" <stefan.eissing@greenbytes.de>
wrote:
> One could advise a client that HTTP_1_1_REQUIRED indicates that the
request uri ref indicates the server realm where this restriction applies.
For Apache httpd at least, client cert renegotiation is a directory based
configuration.
The notion that you might infer something about other resources based on
some unspecified dissection of a URL and a response seems to fragile to be
wise. That suggests something explicit, which leads back to 421.
> Further, a client thus falling back to HTTP/1.1 to trigger the proper TLS
params, *could* try to "Upgrade:" to h2 again on the same request, given
that all security requirements are fulfilled. This is outside the spec atm,
right?
Yeah, TLS implies ALPN.
> (I had already one site with "421 Ping Pong" reported, where the client
got a 421, teared down the connection, opened a new one, got a 421 on a
later request, teared down again, opened exactly as in the beginning a new
one... all this does not match exactly this case, but it shows that there
are interop issues lurking.)
Redirect loops happen too, so I imagine that this can be handled in a
catchall.
The ideal solution is to find ways to address all use cases in HTTP/2. For
that, I agree that client authentication in response to a request will be
needed.