httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: Upgrade Summary
Date Fri, 11 Dec 2015 22:24:27 GMT
On Fri, Dec 11, 2015 at 2:55 PM, Jacob Champion <champion.p@gmail.com>
wrote:

> 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.


The spec describes the exception handling;
  "A client MAY send a list of protocols in the Upgrade
   header field of a request to invite the server to switch to one or
   more of those protocols, in order of descending preference, before
   sending the final response.  A server MAY ignore a received Upgrade
   header field if it wishes to continue using the current protocol on
   that connection.  Upgrade cannot be used to insist on a protocol
   change."
Unambiguous, there is no "error" in not upgrading, period.

If there is no underlying HTTP/1.1 resource resulting from -not- upgrading
the response, or additional constraints are in place (e.g. upgrade required,
http/1 not honored etc) then those are outside of the scope of the Protocol
switch API and fall in the domain of the normal httpd request hook scope,
IMHO.


> 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.


I think we are essentially on the same page.  To the extent that any RFC6455
contradiction to RFC7230 is invalid, RFC7230 is binding, but it doesn't
look that
way to me.  From RFC6455 4.1,

   Once the client's opening handshake has been sent, the client MUST
   wait for a response from the server before sending any further data.
   The client MUST validate the server's response as follows:

   1.  If the status code received from the server is not 101, the
       client handles the response per HTTP [RFC2616
<https://tools.ietf.org/html/rfc2616>] procedures.  In
       particular, the client might perform authentication if it
       receives a 401 status code; the server might redirect the client
       using a 3xx status code (but clients are not required to follow
       them), etc.  Otherwise, proceed as follows.


In other words, in the absence of the websocket module declining to honor
the upgrade request, it still remains an http/1 request and response.
Whatever
auth or other technical details cause that request to fail will be
represented as
an http/1 response.  If the implementer wants to present a successful http/1
response to the request in lieu of establishing a websocket connection with
the corresponding 101-switching protocols, by offering a resource at the
given
URL, that option remains.  If there is no resource except a websocket at
that
URL, an error will occur.

I hope that makes things clearer?

Mime
View raw message