- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Wed, 27 May 2015 09:33:22 -0700
- To: Stefan Eissing <stefan.eissing@greenbytes.de>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 27 May 2015 at 06:03, Stefan Eissing <stefan.eissing@greenbytes.de> wrote: > However, for several reasons, the server might wish to answer such requests with a 421. With the expectation that the client opens/reuses another connection, using the relevant authority in the SNI on that connection. Do client implementors/spec wizard agree that this is a reasonable expectation? That is correct. 421 is specifically intended for this case and others like it. > Opposite to that behavior is a server that does not really care what SNI on a connection was specified and will happily dispatch requests based on stream authority to its virtual servers. Especially servers with wildcard certificates will probably behave like that. This can lead to the client seeing different certificates for the same web resource, depending which connection it already had open when starting a request. Without precaution, it might even get resources from different connections with different certificates for a specific browsing session, e.g. web page. That's already commonplace. Different certificates for connections to what appears to be the same host happen all the time with clustered servers, depending on the nature of the server provisioning, of course. > A user of mod_h2 was confused since one of his test sites with an invalid cert became perfectly browsable as he had a wildcard cert on another vhost and had navigated there first… That sounds perfectly normal. > Is this an issue? What would be the advice for client implementations / server configurations here? Apart from „don’t do that“, of course. I could imagine that some people who want to anti-shard their sites when using HTTP/2 might stumble into such situations. I could recommend that servers have a uniform configuration, but I know that's unrealistic. What's more likely is that you will need a way to test that a cluster is uniformly reachable, which is a different sort of problem. There, you need to ensure that each and every node in the cluster has a valid certificate for the authority (or set of authorities) that it can serve.
Received on Wednesday, 27 May 2015 16:33:49 UTC