Subject: [hybi] Ticket#1 Http Compliance

From: Greg Wilkins <[email-masked]>
Date: Wed, 12 May 2010 15:41:53 +0200

All,

Attached is a proposed diff (from me as individual - not as requirements editor)
to the requirements document for HTTP Compliance.

Formatted as text the patch results in:

   REQ. 7:  When sharing host and "well known" port with HTTP, the
      WebSocket protocol MUST be HTTP/1.1 compliant until both ends have
      established the WebSocket protocol.  The protocol may prohibit the
      usage of specific HTTP features.

   Reason: when operating on the standard HTTP ports, existing web
   infrastructure may handle connections and requests according to
   existing standards prior to the establishment of the new protocol.
   It may also be desirable for consenting clients and servers to use
   HTTP features such as authentication and redirection, prior to
   establishing the websocket handshake.

   However, this requirement does not mean that a websocket
   implementation that is not for general-purpose HTTP, need implement
   any more of the HTTP protocol than is required to establish a
   websocket connection.  The minimal requirements of HTTP are small, as
   indicated by the following extracts of RFC-2616:

   RFC-2616 5.1.1  The methods GET and HEAD MUST be supported by all
      general-purpose servers.  All other methods are OPTIONAL
   RFC-2616 6.1.1  HTTP applications are not required to understand the
      meaning of all registered status codes, though such understanding
      is obviously desirable.  However, applications MUST understand the
      class of any status code, as indicated by the first digit, and
      treat any unrecognized response as being equivalent to the x00
      status code of that class
   RFC-2616 7.1  Unrecognized header fields SHOULD be ignored by the
      recipient and MUST be forwarded by transparent proxies.

My intent with this wording is to not require any more of HTTP
to be implemented my minimal implementations, hence the extracts
from RFC2616 showing that there are few MUSTs in HTTP.

This will allow arbitrary HTTP features to be used if
client and server desire to do so - which seams reasonable
as in many cases the client and server are going to have
full HTTP implementations available.

However, it does allow the protocol to specifically prohibit
the use of features, if for example we decided that redirect
was a undesirable for some reason.

regards

Index: draft-ietf-hybi-websocket-requirements-latest.xml
===================================================================
--- draft-ietf-hybi-websocket-requirements-latest.xml	(revision 2)
+++ draft-ietf-hybi-websocket-requirements-latest.xml	(working copy)
@@ -203,15 +203,42 @@
 
       <t><list style="hanging">
           <t hangText="REQ. 7:">When sharing host and "well known" port with
-          HTTP, the WebSocket protocol MUST be HTTP compatible until both ends
-          have established the WebSocket protocol.</t>
+          HTTP, the WebSocket protocol MUST be HTTP/1.1 compliant until both
+          ends have established the WebSocket protocol. The protocol may
+          prohibit the usage of specific HTTP features.</t>
         </list></t>
 
       <t>Reason: when operating on the standard HTTP ports, existing web
-      infrastructure may handle according to existing standards prior to the
-      establishment of the new protocol.</t>
+      infrastructure may handle connections and requests according to existing
+      standards prior to the establishment of the new protocol. It may also be
+      desirable for consenting clients and servers to use HTTP features such
+      as authentication and redirection, prior to establishing the websocket
+      handshake.</t>
 
+      <t>However, this requirement does not mean that a websocket
+      implementation that is not for general-purpose HTTP, need implement any
+      more of the HTTP protocol than is required to establish a websocket
+      connection. The minimal requirements of HTTP are small, as indicated by
+      the following extracts of RFC-2616:</t>
+
       <t><list style="hanging">
+          <t hangText="RFC-2616 5.1.1">The methods GET and HEAD MUST be
+          supported by all general-purpose servers. All other methods are
+          OPTIONAL</t>
+
+          <t hangText="RFC-2616 6.1.1">HTTP applications are not required to
+          understand the meaning of all registered status codes, though such
+          understanding is obviously desirable. However, applications MUST
+          understand the class of any status code, as indicated by the first
+          digit, and treat any unrecognized response as being equivalent to
+          the x00 status code of that class</t>
+
+          <t hangText="RFC-2616 7.1">Unrecognized header fields SHOULD be
+          ignored by the recipient and MUST be forwarded by transparent
+          proxies. </t>
+        </list></t>
+
+      <t><list style="hanging">
           <t hangText="REQ. 8:">The protocol SHOULD make it possible and
           practical to reuse existing HTTP components where appropriate.</t>
         </list></t>

---

From: Roberto Peon <[email-masked]>
Date: Wed, 12 May 2010 09:20:22 -0700

>      usage of specific HTTP features.

On the handshake? Which features, specifically? I'm asking because the two
sentences here come in fundamental conflict.. It is HTTP/1.1, but not
really.
I'd expect something like:

On a connection established with the expectation that the primary or first
protocol spoken is not WebSocket, the connection shall be considered that
protocol and not WebSocket until a successful UPGRADE or similar
change-of-protocol request is acknowledged. In the case of HTTP,
WebSocket-only server implementations are required to implement the
following subset of rfc2616, but are not required to implement any more than
that.

I apologize for the fast-and-loose verbiage here, but I hope I'm conveying
my intent properly!
-=R

>
> regards
>
>
>
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>
>

---

From: "Anne van Kesteren" <[email-masked]>
Date: Thu, 13 May 2010 08:22:55 +0200

On Wed, 12 May 2010 15:41:53 +0200, Greg Wilkins <[email-masked]> wrote:
> Attached is a proposed diff (from me as individual - not as requirements  
> editor) to the requirements document for HTTP Compliance.

I think it would be good if proposals for new requirements indicated that  
to satisfy them changes to the draft would be required. This especially  
has been a long-standing debate and having it as a debate on requirements  
does not seem like a good idea to me.

-- 
Anne van Kesteren
http://annevankesteren.nl/

---

From: Maciej Stachowiak <[email-masked]>
Date: Thu, 13 May 2010 00:20:51 -0700

Also speaking as an individual...

>      usage of specific HTTP features.

What is the difference between "HTTP/1.1 compatible" and "HTTP/1.1 compliant"? I can't tell if I support this change without understanding what difference is intended

>   indicated by the following extracts of RFC-2616:

I think quoting parts of the HTTP RFC in the requirements document is not a good idea. It seems like too much detail for a requirements document.

>      general-purpose servers.  All other methods are OPTIONAL

If this implies that all WebSocket servers, even WebSocket servers that are standalone and not combined with HTTP servers, must implement GET and HEAD, then that seems like a silly and pointless requirement. What would be the practical benefit of this?

>      status code of that class

What if anything does this imply for WebSocket clients and servers?

>      recipient and MUST be forwarded by transparent proxies.

It's not clear how this requirement constrains the design of the protocol. For example, if WebSocket made the handshake fail if any header fields are present other than a short whitelist, that would be fully consistent with this conformance requirement.

> from RFC2616 showing that there are few MUSTs in HTTP.

Are you claiming these are the only MUST-level requirements that apply to HTTP clients and servers? That seems wrong to me. If you are indeed claiming this I'll be glad to provide counter-examples.

> full HTTP implementations available.

If that is indeed desirable, it seems like a separate requirement from being "HTTP compliant". The handshake could be "HTTP compliant" without enabling this.  

> was a undesirable for some reason.

I agree that we must have the freedom for the protocol to do this. But for this very reason, the change doesn't do what you said in the previous paragraph.

Regards,
Maciej

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 13 May 2010 10:17:02 +0200

Roberto Peon wrote:

> On the handshake? Which features, specifically? 

The requirements can't really talk about handshakes or specific
features - because those are attributes of a particular solution.

> I'm asking because the
> two sentences here come in fundamental conflict.. It is HTTP/1.1, but
> not really.
> On a connection established with the expectation that the primary or
> first protocol spoken is not WebSocket, the connection shall be
> considered that protocol and not WebSocket until a successful UPGRADE or
> similar change-of-protocol request is acknowledged. In the case of HTTP,
> following subset of rfc2616, but are not required to implement any more
> than that.

The context for this requirement is set by a prior requirement:

  REQ. 6:  The WebSocket protocol MUST allow HTTP and WebSocket
           connections to be served from the same port.

the context is also further specified by the opening phrase
of the requirement:  "When sharing host and "well known" port with HTTP, .."

So this requirement only applies to websocket connections that
are established via shared HTTP port.   It does not prevent
there being other mechanisms for opening websocket connections
that do not use a shared HTTP port.

The requirement is trying to remove the doubt about when is
it HTTP and when it is not.    It says that when you are
working on a shared HTTP port, then the connection *is a*
HTTP connection up until both ends have agreed that it
has been upgraded.

regards

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 13 May 2010 10:28:15 +0200

Anne van Kesteren wrote:
>> Attached is a proposed diff (from me as individual - not as
>> requirements editor) to the requirements document for HTTP Compliance.
> 
> I think it would be good if proposals for new requirements indicated
> that to satisfy them changes to the draft would be required. This
> especially has been a long-standing debate and having it as a debate on
> requirements does not seem like a good idea to me.

Anne,

I believe that the intent of the chairs to focus the discussion on
requirements is exactly to help resolve such long standing
debates as HTTP compliance.

If some believe that HTTP compliance is a requirement, while others
think that it is not, then we will never reach agreement on a mechanism
that breaks HTTP compliance.    We first need to resolve if it
is a requirement or not.

It may be that consensus is that we don't need to be HTTP compliant and
then the next time I argue "but you can't do that because it is
not HTTP compliant", I can be politely told that it is not a
requirement and thus we can get on with the rest of the protocol.

regards

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 13 May 2010 11:36:21 +0300

On 5/13/10 11:17 AM, Greg Wilkins wrote:.

> HTTP connection up until both ends have agreed that it
(as individual)

I think it is a good summary of this particular issue!

some people don't care, even when working on a shared HTTP port,
of the HTTP compliance until both ends have agreed that the HTTP 
connection has been upgraded.
other people do care!

this ticket is then to check where really the consensus is!

/Sal

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 13 May 2010 10:51:09 +0200

Maciej Stachowiak wrote:

> What is the difference between "HTTP/1.1 compatible" and "HTTP/1.1
> compliant"? I can't tell if I support this change without understanding
> what difference is intended

The intent of changing to compliant is to strengthen this requirement.
Compliant implies that no part of the HTTP specification will
be violated.

However,  I remind you that this requirement is only in the
explicit circumstances of when websocket is running on
a port shared with HTTP.

When not sharing a HTTP port, a websocket protocol is
free to have it's own handshake (that may be HTTP-like
or a non compliant variation of HTTP).

> I think quoting parts of the HTTP RFC in the requirements document is
> not a good idea. It seems like too much detail for a requirements document.

The intent is to try to communicate that requiring HTTP compliances
is not going to require additional features on minimal implementations.

There are very few MUST's in RFC2616.

The intent of this requirement is more of a you must not break HTTP
(when sharing a port) rather than a you must not implement all of HTTP.

> If this implies that all WebSocket servers, even WebSocket servers that
> are standalone and not combined with HTTP servers, must implement GET
> and HEAD, then that seems like a silly and pointless requirement. What
> would be the practical benefit of this?

This says the exact opposite.

A standalone websocket server is not a general purpose
HTTP server, so this requirement does not apply.  Thus there are
no methods that must be implemented.

> What if anything does this imply for WebSocket clients and servers?

Nothing - and that is the point.

It is indicating that HTTP compliance does not require a websocket
implementation (even one operating on a shared port) to implement
any specific status codes.

> It's not clear how this requirement constrains the design of the
> protocol. For example, if WebSocket made the handshake fail if any
> header fields are present other than a short whitelist, that would be
> fully consistent with this conformance requirement.

It's not intended to constrain the design of the protocol.

IT is indicating that HTTP compliance does not require a
websocket implementation (even one operating on a shared port) to
implement any specific headers.

> Are you claiming these are the only MUST-level requirements that apply
> to HTTP clients and servers? That seems wrong to me. If you are indeed
> claiming this I'll be glad to provide counter-examples.

I'm claiming that a requirement of HTTP compliance will not
require any more of the HTTP specification to be implemented
than already is.

The intent of this requirement is not to force any more
implementation of the HTTP specification.    It is to
prevent the protocol breaking the HTTP specification when
sharing a port with a general purpose HTTP server.

> If that is indeed desirable, it seems like a separate requirement from
> being "HTTP compliant". The handshake could be "HTTP compliant" without
> enabling this.  

This is an argument for HTTP compliance as it prevents an
implementation from disabling arbitrary HTTP features (when
sharing a port with HTTP).

I think it is perfectly OK for the websocket protocol to
specifically disable a feature that is incompatible with
the handshake (eg if redirections are shown to be a security
risk).

> I agree that we must have the freedom for the protocol to do this. But
> for this very reason, the change doesn't do what you said in the
> previous paragraph.

It is entirely possible to limit HTTP features and still
be compliant with the HTTP RFC.

There is a big difference between the protocol choosing not
to support a HTTP feature: eg "a websocket client
shall not follow a redirect sent in response to an upgrade request"
and with the protocol being specified in such a way that
HTTP is actually broken: eg. "a websocket client shall send
non HTTP compliant data on the connection prior to the
upgrade completing".

regards

---

From: Maciej Stachowiak <[email-masked]>
Date: Thu, 13 May 2010 02:13:20 -0700

> Compliant implies that no part of the HTTP specification will

How is the implication of "compatible" different from what you describe for "compliant"? Can you give an example of something that would be HTTP compatible, but not HTTP compliant?

> or a non compliant variation of HTTP).

Having two different handshakes would not be a good idea. Also, the client initiates the handshake and can't tell if the port is being shared with an HTTP server, so there's no opportunity to initiate the handshake differently. Making the server reply differently depending on whether it is standalone, when the client handshake has to be the same, would just create interop problems.

> implement any specific headers.

Listing parts of the HTTP RFC that would have no effect on the protocol design seems unhelpful, especially since the framing material implies they *are* relevant to requirements on the protocol. It seems like none of the three cited requirements would have any particular effect on the design of the WebSocket protocol, from your explanations above.

Regards,
Maciej

---

From: Maciej Stachowiak <[email-masked]>
Date: Thu, 13 May 2010 02:17:02 -0700

> requirement and thus we can get on with the rest of the protocol.

One possible risk: we might fail to reach consensus on a requirement stated in the abstract, when actually it might be possible to reach agreement on a specific technical solution that happens to satisfy everyone's personal requirements. Sometimes it's much harder to evaluate the practical consequences of an abstract requirement than a specific technical solution.

Regards,
Maciej

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 13 May 2010 11:53:59 +0200

Maciej Stachowiak wrote:

> Listing parts of the HTTP RFC that would have no effect on the
> protocol design seems unhelpful

Probably true.   I added them anticipating the concerns
previously expressed that HTTP compliance would require
all implementations to support more of the HTTP protocol.

I was trying to be very clear to say that this requirement
does not mean that more of HTTP must be supported.  It is
only saying that HTTP must be respected prior to the upgrade.

Perhaps the quotes from the RFC should have only been
in my supporting email and not in the reasoning text of
the requirement.  I'm happy to remove them.

> How is the implication of "compatible" different from what you 
> describe for "compliant"? Can you give an example of something
> that would be HTTP compatible, but not HTTP compliant?

telnet is HTTP compatible as I can telnet to a HTTP server
and interoperate with it.

telnet is not HTTP compliant as I can telnet to a
HTTP server and do all sorts of illegal stuff.

If you don't agree that there is significant difference
between the words, then what is the problem changing?

> Having two different handshakes would not be a good idea. 

I'm not advocating that.   I'm only advocating that when you
operate on a shared HTTP port that you are required to be
HTTP compliant until you are upgraded.

> Also,
> he client initiates the handshake and can't tell if the port is
> being shared with an HTTP server, so there's no opportunity to
> initiate the handshake differently. Making the server reply differently
> depending on whether it is standalone, when the client handshake has
> to be the same, would just create interop problems.

I mostly agree.  But this is a reason to always be
HTTP compliant.  I see no reason to ever pretend to be
HTTP without actually being HTTP compliant.   The
overheads of being HTTP compliant are nothing.

regards

---

From: "Anne van Kesteren" <[email-masked]>
Date: Thu, 13 May 2010 12:32:38 +0200

> requirement and thus we can get on with the rest of the protocol.

I guess I don't agree with the requirement then.

I don't believe that shifting the debate to discussing requirements  
instead is a good idea. To me it makes everything less concrete and far  
more vague as to what the intentions are of people proposing the  
requirements. We don't necessarily need to have a (lack of a) requirement  
to do what you say. We could just make a WG decision.

---

From: Maciej Stachowiak <[email-masked]>
Date: Thu, 13 May 2010 03:44:01 -0700

> HTTP server and do all sorts of illegal stuff.

Can you give an example that's relevant to WebSocket? Is there anything in a current or previous draft that's HTTP compatible but not HTTP compliant? That would make it easier to assess the practical impact of this change. WebSocket protocol is not in a situation where you can choose to have syntactically correct HTTP interactions or not, like telnet. It's pretty specific in its requirements.

> If you don't agree that there is significant difference between the words, then what is the problem changing?

I'd like to understand what the difference is, so that I understand the consequences of the change. I don't care that much about the word choice, but since some people apparently do, I'd like to understand what practical difference it makes. If the answer is "no difference" then I would not object.

> overheads of being HTTP compliant are nothing.

Can you give examples of things from the current draft that are not HTTP compliant? I assume the random characters after the request are one thing. Is there anything else?

Cheers,
Maciej

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 13 May 2010 14:33:20 +0200

Anne van Kesteren wrote:

> requirements. We don't necessarily need to have a (lack of a)
> requirement to do what you say. We could just make a WG decision.

Anne,

Is it a requirement to have a requirements document?

I'm afraid that is too meta-physical for me.  I've been asked
to edit the requirements document as part of the IETF process
and that's what I'm attempting to do.

regards

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 13 May 2010 14:51:52 +0200

Maciej Stachowiak wrote:
> Can you give an example that's relevant to WebSocket? Is there anything in a 
> current or previous draft that's HTTP compatible but not HTTP compliant?
> That would make it easier to assess the practical impact of this change.

I believe the current -76 handshake could be described as HTTP compatible,
but it is not HTTP compliant.

The use of redirects and BASIC authentication would also be compliant
features that the current specification does not support because
it is only compatible.

> Can you give examples of things from the current draft that are not HTTP 
> compliant? I assume the random characters after the request are one
> thing. Is there anything else?

The random characters are the most obvious non compliance.

But there is also a restriction on the headers that can be sent,
which I think is boarder-line non compliance, so that
for example user-agent cannot be sent.

There is also a restriction on the server that it's only
valid responses to a handshake is to either accept with
a 101 or to close the connection.  A compliant HTTP server
should be able to respond with any compliant HTTP response.
The websocket specification can say that websocket clients
can ignore all non-101 responses and close the connection,
but they cannot require that a HTTP server act contrary
to the HTTP specification simply because a client made
some mistake in the formulation of their websocket URL (for
example).

In order to claim websocket compliance, I do not want to
have to change my server so that every URL that receives
a bad websocket upgrade has to close the connection without
sending some legal HTTP error response (eg 400 or 404).

regards

---

From: "Anne van Kesteren" <[email-masked]>
Date: Thu, 13 May 2010 14:53:35 +0200

> Is it a requirement to have a requirements document?

I don't know, but in my experience going back to requirements when there  
already is a draft specification is counter-productive. We'll get the same  
debates, only now with more meta. I, for one, am not looking forward to it.

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 13 May 2010 15:11:16 +0200

Anne van Kesteren wrote:
> already is a draft specification is counter-productive. We'll get the
> same debates, only now with more meta. I, for one, am not looking
> forward to it.

Anne,

Personally, I'm not advocating that the WHATWG delay the their
work on the protocol or it's deployment while waiting for the IETF
processes.   There is no requirement that a deployed protocol
is an IETF standard.

I would prefer to see a clear distinction between the spec
as it is being currently deployed and the spec as it is
currently being standardized.

Given the time frames of the IETF processes, my expectation is
that a consensus standard should aim to be the 1.1 version of
the protocol (or maybe an entirely different 2.0 protocol?).

But conversely, just because the browser vendors are further along
their process, it does not mean that the IETF should make an
exception to it's processes when formulating a standard.

regards

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 13 May 2010 16:37:58 +0300

(as chair)

I am not going to spend time to describe the benefit and the opportunity 
to have a list of requirements
before starting to design a protocol!

this wg agreed to have a requirement document, and we have it in the 
charter as mailestone:
http://tools.ietf.org/wg/hybi/charters

I agree with the Anne proposal to indicate if to satisfy a requirement 
are necessary change to the
current version or the protocol.
This is a really good proposal!

I do not think that we should be afraid to the change the current protocol,
in fact as someone as highlighted in another thread
"/we do not yet believe that Web Sockets are at the point where breaking 
changes are yet a problem/"

so I invite everybody to provide only constructive feedback to the 
discussion and moreover not
start a discussion related to the process in a thread related to a 
technical issue!!!
This "Ticket#1 Http Compliance" thread is to discuss the opportunity for 
the protocol to be
HTTP compliant until both ends have agreed that the HTTP connection has 
been upgraded.
If do not want this requirement (that by the way was already discussed 
during the face to face
meeting in Anaheim) please just say it, perhaps explaining why not... 
and we will consider
your opinion as well all the other opinion that will be provided!

If you do want talk about it, please start a separate thread with a 
clear subject!

cheers
Sal

On 5/13/10 3:53 PM, Anne van Kesteren wrote:
> On Thu, 13 May 2010 14:33:20 +0200, Greg Wilkins<[email-masked]>  wrote:
>    

-- 
Salvatore Loreto
www.sloreto.com

---

From: Scott Ferguson <[email-masked]>
Date: Thu, 13 May 2010 08:53:20 -0700

> but it is not HTTP compliant.
Since -76 and HTTP don't even use the same encoding (-76 is UTF-8, while 
HTTP is US-ASCII with ISO-8859-1 used, but obsolete), I'm not sure 
calling them "compatible" is helpful.

The WebSocket handshake needs to be a valid HTTP request. If it's 
possible to create a valid WebSocket handshake that's not a valid HTTP 
request, then we have a problem, whether we call it "compatible" or not.
> sending some legal HTTP error response (eg 400 or 404).
Agreed. This is a big issue. The server must be allowed to return a 
valid HTTP response rejecting the Upgrade request.

Actually, if WebSockets is using HTTP/80 for the handshake, it really 
needs a valid HTTP response on rejected requests and header errors. It's 
just not reasonable to require servers to produce an invalid HTTP 
response if it sees an Upgrade: WebSocket, when the rest of the request 
is normal HTTP.

Clients need to handle valid HTTP rejections anyway, because they need 
to respond properly to normal HTTP server responses, e.g. if the 
WebSocket service goes away or moves.

-- Scott

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 14 May 2010 06:46:36 +0800

I think that Anne's question is a reasonable one to ask.  We need consensus before we can agree that we need requirements. 

I for one disagree with Anne.  We've been operating without a basic set of ground rules and it's lead to long debates that don't resolve.  Setting expectations is costly, but it seems less costly than the sorts of bickering that follows when there are no agreed rules.

It seems that we've been pre-empted though.  The chairs have called consensus on the topic already - we have a requirements document as a WG item.

--Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Greg Wilkins
> Sent: Thursday, 13 May 2010 10:33 PM
> To: [email-masked]
> Subject: Re: [hybi] Ticket#1 Http Compliance
> 
> Anne van Kesteren wrote:
>

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 17 May 2010 11:34:55 +0200

> valid HTTP response rejecting the Upgrade request.

I'd like to expand on this point with examples, to illustrate why
I think compliance is necessary and that websocket clients
are going to end up seeing HTTP responses anyway.

A server that is both a HTTP server and a Websocket server
may use cookies to authenticate users (which is allowed
by current websocket draft).   Frequently such authentication
is implemented by a filter/handler/valve applied in front
of a web application.  Often that filter/handler/valve is
provided by a 3rd party and sometimes imposed by a different
part of an organization.

Without HTTP compliance, if that filter see's an invalid or
missing authentication cookie, then it will have to decide
if it will send a HTTP compliant response (403) or a
Websocket compliant response (close connection).  In all
likelihood, the authenticator will know nothing about
websockets (nor should it) and will send a 403 response.

Similarly, if a developer made a mistake with the URL
and attempted a websocket connection to the wrong resource,
then the request would end up in code that probably knows
nothing about websocket, and will again be faced with the
choice of sending a HTTP compliant response (404) or
a websocket compliant response (close connection).

Alternately, if a deployer made a mistake and deployed
an otherwise correct and capable websocket application
behind something like apache mod_jk, then code that
is fully knowledgeable about websocket would receive
the upgrade request and would want to reject it
(because it knows AJP13 cannot do websocket).   However,
it is not possible for this code to just close
the connection (the connection is on a different machine
and terminated by code that does not know websocket).
So in this case, even code that does know websocket
is only able to send a HTTP compliant response.

So in all these examples, it shows that a combined
HTTP/websocket server is likely to have many situations
where the only possibility for it is to send a HTTP
compliant response.       If a HTTP compliant response
is not websocket compliant, than any problems these
responses cause with 3rd party websocket clients
are likely to be met with
its-your-fault-because-you-are-not-compliant

It is very clear that if a port is to be shared
with HTTP, the websocket clients WILL see
compliant HTTP responses to handshakes.
So clients will need to be written to well handle
such responses, even if in most cases all
non-101 responses are handled as failures.
But a well written client should also be able
to tell it's user the difference between a
2xx, 3xx, 4xx and 5xx etc so they might know
the reason for a failure without the need to
snoop the network.

So if HTTP compliance is required before the
handshake, it is not going to compel clients
to do anything that they would not be doing
anyway.     But it would take away the
dilemma on the server side of should a
HTTP compliant or a websocket compliant
rejection be sent.

regards

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 17 May 2010 11:39:28 +0200

Alternately, if a deployer made a mistake and deployed
an otherwise correct and capable websocket server&application
behind something like apache mod_jk, then code that
is fully aware of websocket would receive the upgrade
request and should reject it because it AJP13 cannot do
websocket.   However, it is not possible for this code
to just close the connection which is on a different machine
and terminated by code that does not know websocket.
So in this case, even code that does know websocket
is only able to send a HTTP compliant response.

So in all these examples, it shows that a combined
HTTP/websocket server is likely to have many situations
where the only possibility is for it to send a HTTP
compliant response.       If a HTTP compliant response
is not websocket compliant, than any problems these
responses cause with 3rd party websocket clients
are likely to be met with "its your fault because
you are not websocket compliant".

It is very clear that if a port is to be shared
with HTTP, then websocket clients WILL see
compliant HTTP responses to handshakes.
Clients will need to be written to well handle
such responses, even if in most cases all
non-101 responses are treated as failures.
But a well written client should also be able
to tell it's user the difference between a
2xx, 3xx, 4xx and 5xx etc so they might know
the reason for a failure without the need to
snoop the network.

HTTP compliant or a Websocket compliant
rejection be sent.

It would also facilitate the possible real
use of other HTTP features and minimal
RTT connection negotiation.

regards