httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Champion <champio...@gmail.com>
Subject Re: Upgrade Summary
Date Fri, 11 Dec 2015 20:55:25 GMT
On 12/11/2015 12:12 PM, William A Rowe Jr wrote:
> On Fri, Dec 11, 2015 at 1:13 PM, Jacob Champion <champion.p@gmail.com
> <mailto:champion.p@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


Mime
View raw message