-
Notifications
You must be signed in to change notification settings - Fork 137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
alt-svc from https (1.1) to https (1.1) #91
Comments
|
I think this is editorial. |
|
Like that? "Special care is needed when the use of an alternative service causes a change in the URI scheme of the transport (e.g., when HTTP traffic is transferred over an HTTPS connection). In cases like these, alternative services MUST NOT be advertised for a protocol that is not designed to carry the scheme. In particular, HTTP/1.1 over TLS cannot carry safely requests for http resources."). |
|
Or: |
|
I think that both could be a little problematic in the sense that they confuse scheme with protocol. How about:
|
|
...but that doesn't address the problem this ticket is about... |
|
Maybe
|
|
proposal from @mnot in #92 (comment) would address this issue as well |
See https://lists.w3.org/Archives/Public/ietf-http-wg/2015JulSep/0193.html:
"Alternative Services MUST NOT be advertised for a protocol that is not designed to carry the scheme. In particular, HTTP/1.1 over TLS cannot carry safely requests for http resources."
...which refers to the :scheme pseudo header field in HTTP/2 (http://greenbytes.de/tech/webdav/rfc7540.html#HttpRequest).
As far as I recall the intention of the statement above is to avoid that when alt-svc is used to move http traffic to a TLSsy port such as 443, the alternative server gets confused about whether it's serving HTTP or HTTPS.
The clause seems to be less relevant when alt-svc is used to load-balance HTTP/1.1 http_s_ traffic.
The text was updated successfully, but these errors were encountered: