Subject: Re: [hybi] Two Questions

From: Andy Green <[email-masked]>
Date: Fri, 01 Apr 2011 10:12:36 +0100

On 04/01/2011 05:09 AM, Somebody in the thread at some point said:
> To all,
>
> I had to ask...
>
> I would like to know, from an HTTP perspective, if a generic and valid
> *HTTP* upgrade request cannot be replied to, per the HTTP spec.  This (a
> none response) seems to be a correct response per the WS 06 spec to an
> invalid *WebSocket* upgrade/handshake request from a client.

The spec can't really control what an intermediary might return anyway. 
  So a restrictive firewall might come back with a 5xx http response 
without even contacting the websocket server.

> Secondly, I am still unclear on whether WS *can* or *must* use ports 80 /
> 443.  Section 1.7 uses the term 'by default'.  I think that implies *can* or
> *should* but not *must*...

It's definitely not 'must', there'd be no point in that restriction. 
What's implied I think is that you'll get best connectivity experience 
considering proxies and so on going via port 80 or as I found in the 
most restrictive case, 443.

-Andy

---

From: "Greg Longtin" <[email-masked]>
Date: Fri, 1 Apr 2011 06:27:48 -0500

Andy,

Thanks for the reply.

How about I rephrase.  Per the HTTP spec, can an HTTP server *not* respond
to a properly formatted but invalid upgrade request from a client?  Or,
*should* an HTTP server respond?

My interpretation of the WS spec is that a non response is correct for
invalid WS upgrade requests.  Does that play well with the HTTP spec?

<Greg>
> > I would like to know, from an HTTP perspective, if a generic and
> > valid *HTTP* upgrade request cannot be replied to, per the HTTP
> > spec.  This (a none response) seems to be a correct response per
> > the WS 06 spec to an invalid *WebSocket* upgrade/handshake
> > request from a client.

<Andy Green's reply>
> without even contacting the websocket server.

Thanks,

Greg Longtin

---

From: David Endicott <[email-masked]>
Date: Fri, 1 Apr 2011 07:47:00 -0400

I believe that HTTP Upgrade is a HTTP request.  As such I would expect an
HTTP response.   Therefore I should expect any valid HTTP response.

I would *strongly* argue that WebSockets must NOT be restricted to a
specific port.

Transport protocols must not be bound to a specific port.

> I had to ask...

All the time, with the asking.    :-)

---

From: Jack Moffitt <[email-masked]>
Date: Fri, 1 Apr 2011 07:54:22 -0600

> The spec can't really control what an intermediary might return anyway.  So
> a restrictive firewall might come back with a 5xx http response without even
> contacting the websocket server.

This can actually be a feature that the underlying protocol doesn't
return certain error codes.  For example, XMPP BOSH defines only 4xx
level errors, not 5xx ones, so any 5xx error must be a failure at an
intermediary. This serves a few purposes:

1) We now can tell at the application layer whether the HTTP failure
represents failure of the BOSH protocol stack, in which case the error
code has an interpretation,

2) We know it failed at the intermediary layer. If it fails on first
request, it's probably a configuration error. If it fails after a
successful request, it's probably a transient issue.

Please note also that XMLHTTPRequest returns a whole slew of non-HTTP
errors (0 and 1xxxx) for things like socket timeouts and dns lookup
failures.  It would be nice if the same errors existed in the JS API,
although I expect that is not a problem for HyBi.

jack.

---

From: SM <[email-masked]>
Date: Fri, 01 Apr 2011 11:05:53 -0700

Hi Greg,
>*should* but not *must*...

 From RFC 2119:

    "In many standards track documents several words are used to signify
    the requirements in the specification.  These words are often
    capitalized."

The only part in the draft which may imply conformance is in some 
parts of Section 3 of draft-ietf-hybi-thewebsocketprotocol-06:

   "If there is no explicit /port/, then: if /secure/ is false, let
    /port/ be 80, otherwise let /port/ be 443."

Regards,
-sm

---

From: Andy Green <[email-masked]>
Date: Fri, 01 Apr 2011 19:17:45 +0100

On 04/01/2011 12:27 PM, Somebody in the thread at some point said:

Hi -

> invalid WS upgrade requests.  Does that play well with the HTTP spec?

A TCP connection can get dropped any time; the http spec important as it 
is in the world can't mandate otherwise.

So it's "compatible with http" if a websocket server doesn't like what 
the client asked for and just closes the socket flat.

For websocket client as mentioned earlier again the specs can only 
really talk about what websocket endpoints should do if compliant.

The rest of the world like proxies, ssh servers or smtp or what have you 
will still "answer the phone" if the websocket client is asked to 
connect to them.  The handshake seems enough to detect it's not a 
websocket server in that case and stop.

-Andy

---

From: Jamie Lokier <[email-masked]>
Date: Thu, 7 Apr 2011 02:38:43 +0100

> is in the world can't mandate otherwise.

It can get dropped, but it's sensible to see it as a fault -
i.e. network or system error to be reported - if it does get dropped
at certain points, for example half-way through the HTTP headers of a
response, or half-way through the body, or shortly after making the
first request on a HTTP connection, which is a POST so unsafe to retry.

This is quite distinct from a non-error TCP connection drop, when a
server drops an idle persistent connection.  In that case the client
should quietly use another one.

If a client expects a response to HTTP Upgrade and gets a closed
socket, it would make sense to treat that as either a fault, a normal
error (such as "can't do websocket") or a rejection - and it would be
good to be clear and consistent about what clients should do.  If
that's only something which happens abnormally, not specified, it
makes sense to treat it as a network or system error.  If it's a
behaviour allowed for in specification, then it makes sense to treat
it as whatever the spec says can do that.

> the client asked for and just closes the socket flat.

I think that behaviour is not compatible with
HTTP-as-pragmatically-practised if it's the _first_ request on a
connection.  HTTP servers are not meant to close sockets without
processing at least one request in a reasonable time frame, with the
exception as ever being if there is some failure to comply due to
network errors, crashed process or whatever.

It matters because if regular HTTP servers did (or do) that in
_normal_ response to a POST request, which is naturally first on the
connection (for this reason), it would be impossible for HTTP clients
to safely retry the request because they can't distinguish this from
POST being accepted, processed, and then something breaking before
they see the response.  So lots of POST requests would break.  So HTTP
servers don't do this in normal operation, including normal HTTP errors.

But because the client _knows_ it is making a WebSocket upgrade
request, and because other HTTP requests (including XmlHttpRequest)
_never_ look like one of these, there is no ambiguity in this case, so
it's not actually harmful.  We were lucky...

> really talk about what websocket endpoints should do if compliant.

Slightly unfortunate, if what they have to do looks like a HTTP
implementation fault (rather than an HTTP error with defined meaning)
prior to getting past the HTTP stage.  But not really harmful.

-- Jamie