Draft: draft-ietf-quic-http

Commentary: in what I believe is the simplest way possible -- point to 8164 and require that be successfully retrieved prior to sending any scheme other than . 
 It would be good if it could be clarified what will happen if someone needs / tries to send a HTTP request with an http:// uri over H3 . I primarily see this to occur when you have a case where you have an HTTP proxy that receives an HTTP request and then have an HTTP/3 connection with the authorative server . If the expectation is that all requests are upgraded by the HTTP/3 sending side , then that needs to be made explicit . 
 I might propose this comes down to a discovery problem for the proxy . What method(s ) do you envisage the proxy used to decide to make an HTTP/3 connection to the authorative server ? This seems related to the discussion in HTTP WG - If    is being used , the flow might be that the proxy attempts to make a cleartext HTTP/1.1 connection to the authoritative server and does an upgrade , as described in RFC 7838 , to HTTP/3 . In which case I do n't think any action is required . If the proxy wants to opportunistically upgrade via some happy eyeballs approach described on , we might want to provide guidance that either 1 ) it should n't be done for client requests with http:// or 2 ) that it should always be done . 
 This is another variant of -- HTTP/2 and HTTP/3 explicitly include the scheme and the authority with all requests , so the server knows what it 's being asked for . The question is how the client decides that a QUIC endpoint is authoritative for this particular URL . RFC 7838 describes how an https://-schemed request might come to be sent to an HTTP/3 endpoint and the resolution of the issue was to ask the HTTP WG to define other ways . Adding RFC 8164 as well , an http://-schemed resource might also be requested over HTTP/3 ; it 's up to the HTTPbis group whether they want to enable a direct upgrade there as well . I do n't currently see any text required for this , but if you have suggestions , I 'm happy to review or expand the discussion to the list . 
 I 'd rather duplicate this to and rely on for this . We were not very careful in that document to avoid mention of the specific HTTP version , but the technique is perfectly portable between versions . We only really intended to put HTTP/1.x off limits . 
 Perhaps " not very careful " was careful enough -- it says " such as HTTP/2 , " and mandates that the protocol needs a way to carry the scheme . HTTP/3 does , so we 're covered . Do we think a reference to 8164 is warranted in the section about finding an HTTP/3 endpoint ? 
 By " not very careful " I was mainly referring to the title :) As for the text , I do n't know . It will depend on what else it says . 
 Discussed in London ; reference 8164 and require the same check when sending a scheme other than "  . "
Paragraph (version B):
Prior to making requests for an origin whose scheme is not "https,"
the client MUST ensure the server is willing to serve that scheme.
If the client intends to make requests for an origin whose scheme is
"http", this means that it MUST obtain a valid "http-opportunistic"
response for the origin as described in RFC8164 prior to making any
such requests.  Other schemes might define other mechanisms.