Subject: [hybi] reuse of port 80/443 in hybi

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 29 Mar 2011 14:23:33 +0200

I am finding it difficult to participate in hybi in any meaningful
way due to the very poor assumption that websockets traffic should
use the same ports as Web traffic.  Apparently, this "decision" was
made on the basis of hums at an in-person WG meeting and the chairs
believe it to be consensus (and thus quash any discussion that has
apparent consensus due to the extent to which people keep bringing
up old issues).  It might even make some sense, given the name of
this working group.

Unfortunately, it is a fatal error.  The rest of the protocol
discussion is predicated on it, and enormously complex, for the
sole reason of that initial error in design.  More the pity.
It assumes that the network infrastructure that currently
monitors and balances traffic over 80/443 is going to instantly
adapt to TCP-over-HTTP, as opposed to treating it like a denial
of service attack.

Browsers are fully capable of opening up new ports in firewalls
simply by concerted use of open standards.  Many other applications
do so without this painful corruption of existing protocols. Yes,
it takes time (but not as much time as one would think).  Yes,
there will be some companies that forcibly block some ports,
just like there are some companies that forcibly block HTTP
sites like facebook.com.  That is their right.  If the protocol
is safe to use, it will be deployable over time.  If not, then
it shouldn't make the Web situation worse by increasing the
amount of packet filtering at firewalls.

So, I don't think the hybi work is worth continuing.  The rest of
the protocol decisions simply don't matter -- any of the already
deployed proprietary hacks are better by default because they
are no worse than hybi and don't have the imprimatur of the IETF.
I'd rather develop a protocol that works with network administration
rather than against it.

I only ask that an IESG note be added to the final specification
to the effect that this protocol knowingly misuses the Internet
for the sake of bypassing organizational security.  Be honest and
let the admins make their own decisions.

Cheers,

Roy T. Fielding                     <http://roy.gbiv.com/>

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 29 Mar 2011 23:42:44 +1100

Roy,

Perhaps the argument should be made to http-bis to remove or restrict
usage of upgrade.  Websocket appears to be a valid usage of that
mechanism and intermediaries and firewalls should support it (or are
free to block it).

However, I also agree that we should have developed a protocol that
would work on dedicated ports and just use upgrade as a fallback.

cheers

On 29 March 2011 23:23, Roy T. Fielding <[email-masked]> wrote:
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: John Tamplin <[email-masked]>
Date: Tue, 29 Mar 2011 08:47:28 -0400

> would work on dedicated ports and just use upgrade as a fallback.

That option was discussed several times, and there was little support for
doing so.

-- 
John A. Tamplin
Software Engineer (GWT), Google

---

From: David Endicott <[email-masked]>
Date: Tue, 29 Mar 2011 12:24:00 -0400

Roy,

With all due respect and forgive me if I have some mistaken assumptions, but
I don't think your concerns are really as much of a problem as you believe.

Since one of the primary intended uses of Websockets is in the context of
browser clients & webservers, it would seem to me that allowing the
client-agent to open the conversation via the webserver (via the HTTP
Upgrade) makes perfect sense.  I've been working on integrating Websockets
on the server side both as an independent process and as part of a WSGI
framework and having it involved with the http server environment is, so
far, making good sense - the static content and the dynamic content are
generally related.

You're concern about "tcp-over-http" I believe is also unfounded.  The
connection through firewalls/proxies would have already been negotiated with
the initial HTTP Upgrade request.  That further traffic is not HTTP seems,
to me, irrelevant.  It would be no different than a normal HTTP
request/response with binary payload.   A proxy/firewall that does not
handle HTTP Upgrade properly is not a problem that WebSockets should be
trying to resolve.  The Upgrade mechanism is well defined and standardized
and intermediaries should be able to handle the repercussions.    Since the
connection has already established and continues as an open connection the
traffic is not TCP over HTTP, it's a pre-existing TCP connection that was
originally used for HTTP.   Would you have similar concerns about a simple
TCP connection opened to an arbitrary port by some (non browser) client
agent?  Intermediaries that mis-handle this type of connection are outside
our domain of concern.  While Websockets should take reasonable steps to not
traumatize existing infrastructure, I don't believe using the HTTP Upgrade
mechanism is going to cause widespread chaos.

Further, I resist the idea that ports & protocols should be intimately
bound.  Ports are a property of IP, and are independent of the higher layer
protocols it's carrying.   HTTP can, and regularly is, served on ports other
than 80.   WebSockets can be considered an extension to a HTTP connection
and could very reasonably be assumed that the same server agent that
provides static HTTP documents will also be providing dynamic WebSocket
delivered content.

While certain ports are "well-known" and and reasonably be assumed to be
providing default services/protocols, I do not believe it should
be mandatory or requisite.   HTTP content and WebSocket content is very
often going to be integrated on the client-agent to produce a unified
end-result.   It seems appropriate to me that the server side of that
conversation can be as well.

You mentioned port 443.  That is not HTTP, that is SSL, but it can carry
HTTP.  In a somewhat similar manner Websockets on port 80 isn't HTTP, but it
was brought into existence by it.    I believe protocols should be port
independent, as they have been since the dawn of IP.   Port related user
infrastructure restrictions are outside our domain of concern - that's their
business.

I reserve the right to deploy a WebSockets server process on any port of my
choosing, and in my opinion, having the ability to integrate it into an
existing http server stack is a "good thing".

While I do have a concern (to be addressed elsewhere) about some of the
specifics of the HTTP Upgrade handshake, the basic idea seem to be rational
and sound and follows logically from WebSockets being the asynchronous
content delivery mechanism that parallels the synchronous content delivery
mechanism of HTTP.   The protocols are transport variations operating in a
related content context.

Regards,
       Dave

---

From: S Moonesamy <[email-masked]>
Date: Tue, 29 Mar 2011 10:31:10 -0700

Hello,
>believe it to be consensus (and thus quash any discussion that has

The following should be read as a datapoint.

There was a discussion about ports in October 2009 ( 
http://www.ietf.org/mail-archive/web/hybi/current/msg00709.html 
).  "HTTP compliance" was tracked as ticket #1 ( 
http://trac.tools.ietf.org/wg/hybi/trac/ticket/1 ).  "HTTP 
compliance" is also mentioned in the minutes of the IETF78 HyBi 
Working Group meeting ( 
http://trac.tools.ietf.org/wg/hybi/minutes?item=minutes78.html 
).  There was a formal declaration of consensus on "HTTP compliance" 
in August 2010 ( 
http://www.ietf.org/mail-archive/web/hybi/current/msg02955.html ).

Regards,
S. Moonesamy
Hybi WG Secretary

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 29 Mar 2011 20:33:36 +0200

On Mar 29, 2011, at 6:24 PM, David Endicott wrote:

> Roy,
> 
> With all due respect and forgive me if I have some mistaken assumptions, but I don't think your concerns are really as much of a problem as you believe.
> 
> Since one of the primary intended uses of Websockets is in the context of browser clients & webservers, it would seem to me that allowing the client-agent to open the conversation via the webserver (via the HTTP Upgrade) makes perfect sense.  I've been working on integrating Websockets on the server side both as an independent process and as part of a WSGI framework and having it involved with the http server environment is, so far, making good sense - the static content and the dynamic content are generally related.

My concern is not about the use of Upgrade.  That, at least, makes
sense once the decision is made to reuse the same connection.

My concern is about the nature of the protocol after the Upgrade
handshake is complete.  WebSockets will not have the same performance
characteristics as the Web.  The connection will stay open a long time,
the messages will be small and occasional in nature, and the TCP
association will persist.  All of those are *good* things if the
surrounding network infrastructure (all the machines that those
bits pass through on their way to the origin server and back) is
prepared for that type of interaction.  If not, then they will be
seen as the equivalent of a denial of service attack.

> You're concern about "tcp-over-http" I believe is also unfounded.  The connection through firewalls/proxies would have already been negotiated with the initial HTTP Upgrade request.  That further traffic is not HTTP seems, to me, irrelevant.  It would be no different than a normal HTTP request/response with binary payload.   A proxy/firewall that does not handle HTTP Upgrade properly is not a problem that WebSockets should be trying to resolve.  The Upgrade mechanism is well defined and standardized and intermediaries should be able to handle the repercussions.    Since the connection has already established and continues as an open connection the traffic is not TCP over HTTP, it's a pre-existing TCP connection that was originally used for HTTP.   Would you have similar concerns about a simple TCP connection opened to an arbitrary port by some (non browser) client agent?  Intermediaries that mis-handle this type of connection are outside our domain of concern.  While Websockets should take reasonable steps to not traumatize existing infrastructure, I don't believe using the HTTP Upgrade mechanism is going to cause widespread chaos.

I am not concerned about the HTTP-aware message processors.
They have the ability to decline the Upgrade.  Other forms
of load-balancing routers do not.

> Further, I resist the idea that ports & protocols should be intimately bound.  Ports are a property of IP, and are independent of the higher layer protocols it's carrying.   HTTP can, and regularly is, served on ports other than 80.   WebSockets can be considered an extension to a HTTP connection and could very reasonably be assumed that the same server agent that provides static HTTP documents will also be providing dynamic WebSocket delivered content.
> 
> While certain ports are "well-known" and and reasonably be assumed to be providing default services/protocols, I do not believe it should be mandatory or requisite.   HTTP content and WebSocket content is very often going to be integrated on the client-agent to produce a unified end-result.   It seems appropriate to me that the server side of that conversation can be as well.
> 
> You mentioned port 443.  That is not HTTP, that is SSL, but it can carry HTTP.  In a somewhat similar manner Websockets on port 80 isn't HTTP, but it was brought into existence by it.    I believe protocols should be port independent, as they have been since the dawn of IP.   Port related user infrastructure restrictions are outside our domain of concern - that's their business.

Nevertheless, your belief does not match deployed network
management products.  We put different architectures on different
standard ports in order to make network admins lives easier.
We don't have to do that for nonstandard ports.

> I reserve the right to deploy a WebSockets server process on any port of my choosing, and in my opinion, having the ability to integrate it into an existing http server stack is a "good thing".
> 
> While I do have a concern (to be addressed elsewhere) about some of the specifics of the HTTP Upgrade handshake, the basic idea seem to be rational and sound and follows logically from WebSockets being the asynchronous content delivery mechanism that parallels the synchronous content delivery mechanism of HTTP.   The protocols are transport variations operating in a related content context.

Umm, they both use TCP.  Good luck keeping those connections open.
HTTP doesn't have asynchronous delivery because that is more
efficiently accomplished via email, IRC, NNTP, or XMPP, not because
the concept is anything new.

Keep in mind that long poll, BOSH, and RTMPT are all techniques
in use today that attempt to do the same thing.  The reasons that
they don't work very well have nothing to do with the HTTP processors
that are sending content.  SSH, in contrast, works quite well.

In any case, I did not send that message to have a discussion about
what hybi should do.  That topic seems to be closed.  It's as if the
WG were charted to get from the top of a building to the bottom of
a building, and someone argued that the most efficient way to do so
is to step out the window.  *shrug*  Once that decision was made,
arguing about the number of rotations or arm waves seems rather
pointless, at least to me.  YMMV.

I just want the spec to be up front about the impact this will
have on organizational policies.  A sort of "Look out below!"
Because that's the kind of warning that IESG notes are good for.

....Roy

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 29 Mar 2011 20:39:02 +0200

> far, making good sense - the static content and the dynamic content are

The server side is indeed a very important aspect in massive hosting
environments.

Right now, web hosting which offers HTTP+HTTPS basically merges the streams
at the boundary and forwards HTTP only through possibly several layers of
proxies and load balancers to the final server. It makes a lot of sense to
be able to reuse that infrastructure and those existing configurations to
automatically make WebSocket possible on those sites. Having to run the
connections via a specific path (and configuration) for the same site is
going to double the work needed to enable the service, which will sensibly
increase its deployment & maintenance cost, and slow down its adoption.

Also, we're much concerned about the ability to quickly detect failures.
When a site is reachable on port 80, we know this channel is open. That
does not mean that websocket will work over that channel, but at least it
is worth trying it. If we used another port, we have no way to know whether
the other port will pass or not, and the typical "firewall silent drop"
that will happen everywhere ports other than 80 are blocked is the worst
behaviour we can dream of, because no feedback is returned to the user
until a connection timeout strikes.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 29 Mar 2011 20:54:57 +0200

> seen as the equivalent of a denial of service attack.

Generally the issues with long connections are not on the infrastructure
in the middle but rather with a threaded origin server that can't accept
many connections and which reserves a lot of resources for an HTTP session,
waiting for an application component to dare respond.

HTTP timeouts will obviously always be an issue, but at least now we'll be
more on "tunnel" timeouts (comparable to what can happen through proxies
after a CONNECT request) than response timeouts. Also, WS makes a difference
between expected and unexpected closes, in order to be able to reconnect if
the close is unexpected. Maybe we should add more restrictions on the
reconnect algorithm to use ? That said, whatever the port, if connection
floods happen, they will always look like DoS attacks.

> of load-balancing routers do not.

I disagree here. Routers are the least impacted equipments on the chain.
You can have firewalls, but they'll suffer the same from a large number
of connections on any port. Load balancers are designed to deal with very
large amounts of concurrent connections and nowadays are L7-aware, so they
will even be able to affect different service qualities depending on the
presence of the Upgrade header, or serve them on different server farms.

> standard ports in order to make network admins lives easier.

That's true, but security admins tend to prefer it the other way
around, the less open ports, the less attack vectors. Also, due to
the generalization of keep-alive, HTTP connections tend to last long
too nowadays, so I really don't see that much of a difference between
both types of traffic.

When you look at an HTTP connection, you'll find many short exchanges
with short and medium pauses in between (tens of ms and seconds). WS
will basically look like that too.

> that are sending content.  SSH, in contrast, works quite well.

Interestingly, from where I work, my SSH passes over a long HTTPS chain
all the way to home, because that's the only service I have access to,
and my connections happily last the whole day :-)

Regards,
Willy

---

From: Bruce Atherton <[email-masked]>
Date: Tue, 29 Mar 2011 12:48:44 -0700

> let the admins make their own decisions.

I understand what you are saying, but can you at least accept that some 
people might not believe that this is a misuse of the Internet? That an 
argument can be made that this is a perfectly legitimate use of Upgrade?

When you take the inflammatory rhetoric out of it, it sounds like you 
are asking for a note warning that Websockets is a different protocol 
than HTTP and could well have traffic that looks different. Is this 
really a surprise to anyone? Is it necessary to issue a warning about that?

---

From: Dave Cridland <[email-masked]>
Date: Tue, 29 Mar 2011 21:23:07 +0100

Roy,

I didn't want to reply to this too hastily, because it is in no small  
part an invitation to throw away almost everything we have and start  
over, but nonetheless I suspect that it's worthwhile carefully  
evaluating what you say.

> up old issues).  It might even make some sense, given the name of
By using grammatically incorrect quotes around the word "decision",  
you appear to be strongly implying that the consensus arrived at  
there is invalid. I'd like to note SM's detailing of this point - it  
was, in fact, one of the least contentious items this working group  
has ever agreed upon. So please accept that the decision was made for  
good reason, with the facts we had at the time carefully weighed. The  
question worth posing is whether sufficient new facts have come to  
light that we should consider revisiting this decision whilst we  
still can.

> adapt to TCP-over-HTTP, as opposed to treating it like a denial
The implication here is that it is a decision that needs revisiting.

I appreciate that the simplest way to address this comment is to  
declare it too late, but I'd like to highlight the first reason you  
give - that "the rest of the protocol discussion is predicated on  
it". This, I think, is worthwhile to consider - the masking, the HTTP  
upgrade handshake, and so on are all solely there to combat issues  
relating to the choice to run over a network expecting HTTP. In fact,  
not only that, but they're there to combat the problem that the  
intermediaries and other actors within this network don't even fully  
understand HTTP.

> amount of packet filtering at firewalls.
This is true; however one assumes that if companies are able to block  
Facebook, they can also choose to block Websockets. In fact I suspect  
that companies blocking specific sites might well end up blocking  
WebSockets as well by default, as they're likely to treat it as  
erroneous traffic as you hint above.

> I'd rather develop a protocol that works with network administration
The question is not simply whether you consider the hybi work  
worthwhile to continue, however.

> let the admins make their own decisions.

At this point in time, I don't think this is suitable; we should  
either consider changing the protocol or decide that what we have is  
indeed correct, even in the face of the difficulties of passing  
through the HTTP layer.

So either we:

1) Continue to use port 80 and HTTP Upgrade, and by inference we need  
masking, fast-fail detection in the Upgrade, and so on, or:

2) Switch to a different port and by inference drop any need for  
masking. (We'd still need a fast-fail handshake, to avoid  
cross-protocol attacks, but we could this time consider other designs  
entirely).

I suspect, without looking, that we have spent approximately the past  
9 months solely on issues relating to the use of HTTP. On the one  
hand, we're approaching what seems like a solution, and moreover,  
this is a sunk cost. On the other, it's entirely possible that we  
might find another issue with running over the HTTP network, and  
switching to a different port (or rather, switching to having no  
expectation that we're running over HTTP) would entirely liberate us.  
But to change means throwing away 9 months of work, which means it  
simply cannot be a quick decision.

So rather than suggest any kind of decision be made at this point,  
I'd like to instead ask this:

If I (and anyone else interested) were to go away - by which I mean  
form a small design team off this list - and come back in a week or  
two with a complete proposal which is based around the premise of  
*not* using HTTP, does the group feel it would be able to consider it?

I'm suggesting bringing a complete I-D, essentially close to  
RFC-ready in the eyes of those involved, and not drawing on the  
group's energy at this time to write it.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 29 Mar 2011 22:35:57 +0200

On Mar 29, 2011, at 9:48 PM, Bruce Atherton wrote:

> I understand what you are saying, but can you at least accept that some people might not believe that this is a misuse of the Internet? That an argument can be made that this is a perfectly legitimate use of Upgrade?

Yes.  The world is full of arguments.  You can put that in an IESG
note as well.  You don't have to agree with me. 

> When you take the inflammatory rhetoric out of it, it sounds like you are asking for a note warning that Websockets is a different protocol than HTTP and could well have traffic that looks different. Is this really a surprise to anyone? Is it necessary to issue a warning about that?

It is a different protocol, with different operational characteristics,
on a reserved port.  That matters to some people.  It may mean that they
need to change their network configuration accordingly, beyond what one
would expect from an apps-area proposed standard.  It may also mean that
they need to update their general-purpose webserver to one that blocks
upgrade by default.  This is the kind of thing that the IETF warns about
when they publish a new spec that does something wonky.

If I knew exactly what damage this will do, I would be more specific.
I tried to stay interested long enough to figure that out, but I found
today's WG meeting to be intolerable.

....Roy

---

From: Bruce Atherton <[email-masked]>
Date: Tue, 29 Mar 2011 13:49:59 -0700

On 29/03/2011 1:35 PM, Roy T. Fielding wrote:
> on a reserved port.  That matters to some people.

Then surely the note you want belongs on the definition for HTTP 
Upgrade, not on the protocols that legitimately use it.

---

From: Dave Cridland <[email-masked]>
Date: Tue, 29 Mar 2011 22:26:07 +0100

> until a connection timeout strikes.

Just on this point, it's not entirely clear that we wouldn't have  
connection timeout issues even with an HTTP Upgrade - we have  
generally assumed that intermediaries may choke or otherwise behave  
oddly when faced with websocket traffic, hence the various handshake  
designs.

However, I don't think it'll be much of an issue; the Javascript API  
in use here is highly asynchronous, and so applications can be  
written very easily to handle long startups and potential failure.  
I'd expect content panes within the page being viewed to have default  
content, a warning, splash-screen, etc whilst the WebSocket starts  
up, and it'd have the same effect as the <no*> tags used to back when  
web designers couldn't rely on frames and scripting being available.

Again, this applies in either case.

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Tue, 29 Mar 2011 22:30:48 +0100

> that are sending content.  SSH, in contrast, works quite well.

Just to piss on all fires equally, the only issue with BOSH I've ever  
been aware of is its bandwidth overhead due to the HTTP framing, and  
that only when compared to bare XMPP in mobile situations -  
otherwise, BOSH has a 100% "penetration" capability and is entirely  
compliant with the HTTP spec (although it does, notoriously, benefit  
from pipelining POST requests). So within the constraint of "runs  
within HTTP", BOSH does indeed "work very well", and to all intents  
and purposes behaves identically to an HTTP processor sending content.

Dave.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 29 Mar 2011 23:55:28 +0200

On Mar 29, 2011, at 10:49 PM, Bruce Atherton wrote:

> Then surely the note you want belongs on the definition for HTTP Upgrade, not on the protocols that legitimately use it.

No.  If people want to find out about this new protocol published
by the IETF, they won't be looking for warnings deep within the
HTTP spec.

HTTP Upgrade's definition is not relevant to this discussion. Why
you keep bringing it up is beyond me, and I'm the guy that invented it.
Upgrade was created specifically to upgrade the protocol to future
incompatible versions of HTTP (HTTPng, waka, or other proposed
replacements for HTTP/1.x that share the same operational behavior
as HTTP but with an incompatible syntax that needs a bootstrap in
order to be deployed).  I have not tested Upgrade with different
architectures, nor do I particularly care whether anyone thinks that
is a legitimate use case.  It simply doesn't matter.  What matters
is what happens after the Upgrade and how that impacts deployed
network architecture.

I'd suggest exactly the same warning if hybi was being performed
without an Upgrade, on a new connection of port 80.

Again, this is only a request for an IESG note.  This is not
reopening the decision in hybi, this is not in scope for the working
group draft, this is not subject to the working group's interesting
method of obtaining consensus by polling people at meetings and then
closing all further discussion on the issue.  What this is, though,
is a request from one of the authors of HTTP to the IESG, because
they can think about it themselves once the issue is brought to
their attention (and I can wash my hands of it).  Normally I would
wait until last call, but the WG chairs have insisted that this
won't be changed and the ADs seem to agree -- so why wait?

....Roy

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 30 Mar 2011 10:08:05 +1100

Roy,

I hate to quibble with the author, but RFC2616 says:

 "The Upgrade header field is intended to provide a simple mechanism
for transition from HTTP/1.1 to some other, incompatible protocol."

and the examples listed include IRC and RTA/x11.      So it does not
appear that the specification reflects the limited scope that you
suggest for upgrade.   I also question the wisdom of having an upgrade
mechanism that only supports protocols that can be imagined at the
time the mechanism was specified.

Also, consider an upgrade to TLS, which RFC2817 implies is an intended
use for the mechanism. In many ways an upgrade to TLS is similar to
upgrade to websockets:
  + after the upgrade the framing is no longer HTTP framing, but TLS,
so the intermediaries may have to adopt different data forwarding
strategies
  +  content filters/loggers can no longer inspect HTTP
request/responses and have to consider applying a blanket block or
allowing all content unfiltered.
  + once upgraded to TLS, the protocol on the wire has closing
handshakes that would be best respected rather than having
intermediaries timeout the connection (silently or otherwise).
Such TLS connections would benefit from declared timeouts/keep-alive
values as well as websocket.
 + the ability to renegotiate on TLS (Eg ask for client certs etc)
also means that the data flow is not a pure client server
conversation, so intermediaries will have to be bidirection.

So I think people bring up upgrades definition because if
intermediaries we able to be written to well support upgrade to TLS
(or other protocols), then they should be able to support something
like websocket.

In fact, for many intermediaries, upgrade to websocket should be
better than upgrade to TLS, because hopefully they will be able to see
well defined framing that will allow them to have sane forwarding and
content inspection policies (of course things like stream-deflate and
other extensions that mess with the framing make this less so).

So rather than an abuse of the upgrade mechanism - I see that
websockets is requiring that intermediaries have good implementations
of it.   I think websockets also highlights existing flaws with lack
of knowledge of timeouts on intermediaries.

regards

---

From: Bruce Atherton <[email-masked]>
Date: Tue, 29 Mar 2011 16:18:08 -0700

> by the IETF, they won't be looking for warnings deep within the

Anyone looking at the Websockets spec is going to realize very quickly 
that it is a "different protocol" and that it uses the same default 
ports as HTTP. The people I would worry about (if I thought this issue 
was worth worrying about) are the ones who are unaware of and have no 
interest in Websockets, but that do have an interest in HTTP and are 
likely to keep up on the HTTP spec.

> you keep bringing it up is beyond me, and I'm the guy that invented it.

I bring it up is because it is the standard-blessed method of switching 
an HTTP connection to a different protocol. This use is not the one you 
envisioned for it, but I haven't seen anyone claim this use is in 
violation of any spec. Any number of different protocols, both standard 
and proprietary, could (and perhaps eventually will) do the same thing.

If switching the protocol from HTTP is such a concern, then the proper 
place to address it is where the definition for switching is defined.

> without an Upgrade, on a new connection of port 80.

Fair enough. Then the warning you want should go on the identification 
of port 80 as the default in the HTTP spec, mentioning that it is 
possible for non-HTTP servers, or HTTP servers that also spoke different 
protocols, to be listening on it. I think most people would categorize 
the warning as belonging to the category of "bleedin' obvious", but that 
is just my opinion.

---

From: Joe Hildebrand <[email-masked]>
Date: Wed, 30 Mar 2011 01:51:59 +0200

On 3/29/11 11:55 PM, "Roy T. Fielding" <[email-masked]> wrote:

> this is not subject to the working group's interesting
> closing all further discussion on the issue.

To be clear, the intent was to see if any progress could be made on an issue
that has had us blocked for quite a while, fashion a proposal that would be
sent to the list, and have discussion on the proposal on the list before any
consensus was declared.  We were running out of time at the end and didn't
make that clear, for which I absolutely apologize.

As well and as others have mentioned, we've had a history of folks with less
deeply thought-out opinions than the ones you've expressed stopping by the
working group to derail the tenuous progress we've been able to eke out by
revisiting everything we all dislike but are just barely willing to all
tolerate.  As such, there are more antibodies than usual to newcomers, for
which we probably ought to post an apology to the list once a week.
Unfortunately, there's so much traffic I doubt anyone would see it.

What we have said repeatedly is that the final document will have to reflect
the consensus of the working group, including anything we've decided to put
on hold so that we could make progress in other areas.  If the people with
issues are still around by the time we get to WGLC, the group would have to
deal with those issues.

This is all Sal and Gabriel's issue now; I just wanted to clarify what was
intended at the time.

-- 
Joe Hildebrand
(as individual!)