On 12/11/2015 12:12 PM, William A Rowe Jr wrote:
On Fri, Dec 11, 2015 at 1:13 PM, Jacob Champion <champio...@gmail.com
<mailto:champio...@gmail.com>> wrote:
On 12/11/2015 02:36 AM, Bert Huijben wrote:
Not upgrading is 100% better than failing.
...except for those protocols for which failure instead of upgrade
is *required* by their spec (e.g. WebSocket).
No, no protocol overrides the HTTP/1 RFCs *until* 101-switching
protocols has occurred at which point the new protocol definition is in
force, this behavior is all defined by RFC7230 section 6.7.
That additional constraint doesn't conflict with any part of HTTP/1.1,
as far as I can tell. Returning 4xx directly to an Upgrade request is
allowed within HTTP/1.1, right? The spec says nothing about the internal
server architecture.
If there is an http:// representation of the websocket resource, that is
served instead of the 101-switching protocols. If there isn't such a
representation, then the request of course does fail :)
I have to serve two masters here. All of the following are allowed by
RFCs 723x, upon receiving a WebSocket upgrade offer:
1) Upgrade the connection to WebSocket.
2) Ignore the upgrade entirely, and continue processing as a normal HTTP
request, which may or may not fail for any number of reasons.
3) Return a 4xx *immediately*. (This is allowed, in that it is not
disallowed: from the point of view of 723x, it's as if the server
ignored the upgrade but found something otherwise objectionable in the
request.)
RFC 6455 removes 2) from my list of choices. There is no conflict
between the specifications here, only a reduction in available options
for the server.
Protocol switch implementations need to have the opportunity to fail
after they have been selected for that reason, but of course the TLS
and HTTP/2 implementations should/would not make use of that.
Any module can cause a request to fail for any of hundreds of reasons,
we must avoid that logic in the Protocol API schema because the protocol
handler module can deal with this in any of the request hooks it likes
and is most appropriate for the failure case.
As long as I can still satisfy 6455, I have no objection.
In other words, there is one and only one recognized mechanism to establish
a TLS h2 connection. I don't think we want to honor other mechanics.
I'm inclined to agree.
IMHO, dedicated clients who are serious about WebSocket security
will have connected via a wss:// connection instead of upgrading
from an initially unsecure connection. (I'm not saying it's
impossible to design a secure system that uses an upgrade, but the
percentage of users who can get it 100% right is likely to be low.)
Your call as a websocket implementer, but I'd be inclined to ignore this
combination just as with TLS+h2c.
+1.
--Jacob
