Skip to content

Conversation

@ioquatix
Copy link
Member

@ioquatix ioquatix commented Jun 14, 2024

cc @Earlopain @byroot

Types of Changes

  • New feature.

Contribution

@ioquatix ioquatix force-pushed the pitchfork-rack-3 branch 2 times, most recently from e93feaf to 8a776af Compare June 14, 2024 15:42
@Earlopain
Copy link
Contributor

Earlopain commented Jun 14, 2024

Is websocket support optional? I think this is the corresponding spec PR rack/rack#1954 formalizing it.

I see your PR for puma at puma/puma#3399, but then it looks like it supported websockets a while ago already puma/puma#3399

@ioquatix
Copy link
Member Author

rack.protocol is not needed for websockets, only correct handling of connection upgrade. I just fixed this in protocol-rack and it fixed puma's tests here:

image

It should be the same for Pitchfork... let me check the errors.

@ioquatix
Copy link
Member Author

Here is the response we are generating on the server:

{:response=>
  [101,
   {"sec-websocket-extensions"=>
     ["permessage-deflate;client_max_window_bits=15"],
    "sec-websocket-accept"=>["2RWck3vRgnko6Ww+leXxh3c/nhU="],
    "upgrade"=>"websocket",
    "connection"=>"upgrade"},
   #<Method: Async::HTTP::Body::Hijack#call(stream) /Users/samuel/.gem/ruby/3.3.2/gems/async-http-0.67.1/lib/async/http/body/hijack.rb:38>]}

And here is how it ends up on the client:

{:version=>"HTTP/1.1",
 :status=>101,
 :headers=>
  #<Protocol::HTTP::Headers [["Date", "Fri, 14 Jun 2024 16:56:46 GMT"], ["Connection", "close"], ["sec-websocket-extensions", "permessage-deflate;client_max_window_bits=15"], ["sec-websocket-accept", "2RWck3vRgnko6Ww+leXxh3c/nhU="], ["upgrade", "websocket"]]>}
{:body=>nil}

From what I can see, for some reason, the connection header is not set correctly.

@Earlopain
Copy link
Contributor

Unicorn/Pitchfork hardcode the connection header https://github.com/Shopify/pitchfork/blob/79ba8e9f0468829af18b46027c123f9d5bcb3dd8/lib/pitchfork/http_response.rb#L53-L58

@ioquatix
Copy link
Member Author

Nice find. I guess that's the problem then.

@ioquatix
Copy link
Member Author

There are two options:

  1. Correctly handle response with connection: upgrade.
  2. If pitchfork wants to have more control over the upgrade process, it should use rack.protocol.

@byroot
Copy link

byroot commented Jun 14, 2024

There is no point supporting websockets in Pitchfork or Unicorn. They entirely go against what it's built for. Pitchfork will remain a pure HTTP/1.1 server.

@ioquatix
Copy link
Member Author

@byroot We are talking about connection: upgrade, not websockets specifically. Websockets is just a reasonable test for that functionality.

In any case, if you don't want to support it, you should delete the HTTP_UPGRADE in the request header before invoking the app, otherwise there is no way for apps to know that you don't support it.

@ioquatix ioquatix force-pushed the pitchfork-rack-3 branch from 4347af3 to 2c0412a Compare July 2, 2024 11:51
@ioquatix ioquatix force-pushed the main branch 4 times, most recently from 1353780 to 9be2b9e Compare March 1, 2025 07:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants