Require 8164 validation for non-https origins #2973
Conversation
MikeBishop
added
design
draft-ietf-quic-http.md
Outdated
| @@ -381,6 +381,10 @@ certificate for the origin before considering it authoritative. Clients MUST NOT | |||
| assume that an HTTP/3 endpoint is authoritative for other origins without an | |||
| explicit signal. | |||
|
|
|||
| If the client intends to make requests for an origin containing a scheme other | |||
| than "https", it MUST also obtain a valid `http-opportunistic` response for the | |||
There was a problem hiding this comment.
I think that this requirement only applies to the "http" scheme. It would not apply to the "ni" scheme, for instance.
There was a problem hiding this comment.
I'm of split opinion on that. On the one hand, "http-opportunistic" is defined for "http"; on the other hand, you still really want to know that the connection is capable of handling a non-https URI scheme before you send it.
There was a problem hiding this comment.
Yes, but the point of this is to point at a specific mechanism, which only applies to "http". I'd be OK with leaving an impression that other protocols might need similar checks, that might be OK with me, but coming right out and saying that they definitely do is a bit of a big deal.
Saying that they have to use the HTTP mechanism is just wrong. Part of the way in which that mechanism was designed was in response to HTTP-specific problems. I'm sure that HTTP isn't unique in this regard, but it doesn't mean that you can't just start using "new-uri-scheme" without additional safeguards if that scheme was designed that way.
There was a problem hiding this comment.
I agree to what @martinthomson says. Unrelated and yet related I just fought (and lost) the Google Layer 7 load balancer because it insisted doing http health checks on a port that speaks websockets but does not serve http pages on the same port. In my case a tcp health check would have worked, but the point is that assuming that everything is http is not good.
There was a problem hiding this comment.
Try this version.
Fixes #2439 in what I believe is the simplest way possible -- point to 8164 and require that
http-opportunisticbe successfully retrieved prior to sending any scheme other thanhttps.