I apologize, but I am not sure the usual procedure regarding changes. What
is the next step? Should I put together a change that simply looks for
status codes less than 200, but that is not 101? Or did we need more
discussion?
I see your point about HSTS. I am not familiar enough with HAProxy code
base to know what impact this change will have to HSTS and other features
that rely on the HTTP headers.
- Ryan
On Wed, Aug 20, 2014 at 9:03 AM, Lukas Tribus <luky...@hotmail.com> wrote:
> Hi Ryan,
>
>
> > I recently started investigating using HAProxy to ensure that multiple
> > WebSocket connections from the same browser (or device) end up
> > communicating with the same application server. Forwarding all
> > connections from the same origin to the respective application server
> > greatly reduces the complexity on the application.
> >
> > My setup is simple: 1 HAProxy in front, 2 App servers on the back. The
> > browser makes several connections via WebSockets (using ws:// or
> > wss://). My goal is to have those connections all go to the same app
> > server. When a new browser is opened on another PC or device then those
> > will go to the other server (round-robin), etc.
> >
> > HAProxy was easy enough to configure and I decided to use the cookie
> > injection persistence method rather than URL parameter, HTTP header
> > field, or cookie modification (e.g. JSESSIONID) since it seemed the
> > most transparent and straightforward. However, I noticed it wasn't
> > forwarding the subsequent WebSocket connections to the same application
> > server. I started to sniff the packets to see what the HTTP response
> > from HAProxy looked like and found that the cookie wasn't present. I
> > did notice, however, that the cookie was present with non-WebSocket
> > HTTP responses. This led me to the source code proto_http.c to see if
> > there was any code that treated WebSocket handshakes differently.
> > Nothing really stood out. However, I did notice that around line 6305
> > there is a check for status codes less than 200. In the event that the
> > status code is less than 200 it skips the header mangling. Note that
> > WebSocket HTTP responses are usually '101 Switching Protocols'. This
> > means that the initial response from the application server will not
> > have the cookie injected into the response via HAProxy. If I comment
> > out the goto, things work as I would expect.
> >
> > My question is, is this line really necessary? I understand that the
> > HTTP RFC indicates that for 1xx responses that the following header
> > fields are optional, but does that mean that the injection should not
> > be done? What if I were to update the code so that it was a little more
> > stateful and WebSocket aware so that in the event that the
> > request/response was WebSockets it would perform the header mangling?
>
> Yes, I wonder if we need this condition at all.
>
> Since commit 628c40cd961d ("MEDIUM: http: move skipping of 100-continue
> earlier") a "100 continue" response doesn't even make it to that condition.
>
> Webdav has a "102 Processing" response, but I doubt it would do harm it
> if we would add response headers or cookies there.
>
>
> Of course, to keep the change minimal we could just make an exception
> for 101.
>
>
>
> Note that the same issue applies to the add-response headers feature,
> with the same condition just some 20 lines above this one.
>
> For example, if we would like to enable HSTS but only use HTTP to
> upgrade to WS, haproxy would never be able to send the hsts header.
>
>
>
> Willy, whats your opinion on this, is there a reason to keep the
> condition and make an exception for status 101, or should we remove
> the check entirely?
>
>
>
>
> Regards,
>
> Lukas
>
>
