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