Re: [hybi] Additional HTTP headers on upgrade request?

[Willy Tarreau <[e-mail]>]

On Wed, Jul 21, 2010 at 11:49:27AM +1000, Greg Wilkins wrote:
> I'll try writing that again in fully formed English sentences this time
> (sorry too much in a rush):
> 
> 
> Ian,
> 
> it is a little disingenuous of you to fall back on the "what's the use
> case?" stone wall
> on topics like this that have been long discussed and people have given many
> use
> cases at length.   You might not understand and/or agree with the use cases
> presented,
> but that is entirely different to pretending that others have not motivated
> their contributions
> to the discussion with good reasoning.
> 
> The result of continually asking "what is the use-case" when it has already
> been explained
> many times, is that the list just goes around and around in endless circles.
> 
> In this particular case, it has been long argued that arbitrary headers
> should be allowed in
> the handshake for flexibility and anticipation of future needs.   You've
> refuted the need for
> generally extensible header.  Now  Doug motivated his comment with the
> specific
> use-case of using user-agent for dealing with browser quirks.

And I see a very important one concerning cookies. Cookies are important
to the server but also to the infrastructure. They're used a lot to
enable "persistence" or "stickiness", depending how it's called. They
make it possible for server-side load balancers to direct the users's
connection to the same server he was on previous connection. This is
of particular importance here because most often we'll need the WS
connection to reach the same server as the one which initiated a local
context. And for this it is important to be able to match reliable
content in the request. This is normally performed using cookies that
are assigned by either the server, the load balancer or sometimes even
some JS on the client.

This is one more reason to support standard headers with standard HTTP
in the handshake.

> Let's flip this around the otherway... because allowing arbitrary headers is
> not really
> a feature to be added to  websocket  because before the upgrade the
> connection
> is HTTP and thus arbitrary headers are by default allowed.
> 
> In essence, you are trying to add a "feature" to the websocket handshake to
> prevent
> the addition of arbitrary headers.
> 
> So what is the use-case for that?  I know you have previously argued that
> somehow it
> would be easier for amateurs not to have to write code to ignore headers
> (surely they
> just don't write code to handle them?), but the amateur programmer
> requirement has been
> widely rejected.     Is there any other use-case that motivates the
> rejection of websocket
> handshakes due to the presence of additional ignorable headers?

Indeed, why break something which works well, is well understood, well
mastered and well debugged ?

Willy