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 22:47:47 GMT
n 12/11/2015 02:24 PM, William A Rowe Jr wrote:
> On Fri, Dec 11, 2015 at 2:55 PM, Jacob Champion <champion.p@gmail.com
> <mailto:champion.p@gmail.com>> wrote:
>     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.

Is your argument that, because the spec does not explicitly say that the 
server may take some action, such an action is prohibited?

> To the extent that any RFC6455
> contradiction to RFC7230 is invalid, RFC7230 is binding,

Agreed.

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

Agreed. A properly implemented WebSocket client is also, by necessity, 
an HTTP/1.1 client, because the server may not have any idea what 
WebSocket is.

> Whatever auth or other technical details cause that request to fail will be
> represented as an http/1 response.

Yes.

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

This is where we disagree, for the case of WebSocket and WebSocket 
alone. RFC 6455 4.2.1:

    The client's opening handshake consists of the following parts.  If
    the server, while reading the handshake, finds that the client did
    not send a handshake that matches the description below (note that as
    per [RFC2616], the order of the header fields is not important),
    including but not limited to any violations of the ABNF grammar
    specified for the components of the handshake, the server MUST stop
    processing the client's handshake and return an HTTP response with an
    appropriate error code (such as 400 Bad Request).

I maintain that this requirement (stop, do not pass Go, return an error 
immediately) is not in conflict with 723x, but I am open to persuasion 
otherwise. At the moment, I just don't agree that the paragraph you 
cited above (RFC 7230 6.7)  prohibits this behavior. Are there other 
cases you can show me where omission is tantamount to prohibition?

--Jacob

Mime
View raw message