-
-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Missing headers in HTTP/1.x upgrade response #55
Comments
Upgrading a connection is HTTP version specific. HTTP/0.9 - HTTP/1.1 use the Because of this, we need to generate a HTTP version specific response. In To avoid having to specify these headers explicitly,
So, the reason for the This is why you get such a warning: In this case, what you want is There are tests here which validate the correct behaviour of a wide range of servers: https://github.com/socketry/rack-conform/blob/main/test/rack/conform/websocket.rb however this will only work on Rack 3+. In terms of your code, the The way that gets mapped back out is by The best behaviour would be for |
If you are running on Puma (and Rack 3+), the following compatibility middleware should work: class RackProtocolToConnectionUpgrade
def initialize(app)
@app = app
end
def call(env)
status, headers, body = @app.call(env)
if protocol = headers.delete('rack.protocol')
headers['upgrade'] = protocol
headers['connection'] = 'upgrade'
end
return status, headers, body
end
end I only eyeballed the code, but this should be the gist of it. If you are on Rack 2.x, you need to use |
Thank you for your thorough explanation. I can confirm that the compatibility middleware resolves the issue. For safety, I'm only setting the headers when Now the concept described in rack/rack#1946 totally makes sense. I agree in principle that the app server (Puma, Falcon, WEBrick, etc.) should be required to manage |
Please add your feedback to that issue if you have time. I'm happy this fixed your issue. |
I've been using
Async::Websocket::Adapters::Rails
(source) with Puma and it's very useful. But when Puma is behind HAProxy, WebSocket connection negotiation fails with status code 502.I found this HAProxy blog post, which provides the following guidance:
This requirement agrees with RFC 7231 section 6.2.2, which says
The MDN Web Docs have a note that
I added both headers to the HTTP/1.x upgrade response in https://github.com/wtn/async-websocket/commit/672d54bf1f0af5828c7e16775b588053700508f5, and that resolved the problem.
However, this change resulted in warnings when running the tests, so I opened this issue to discuss.
The text was updated successfully, but these errors were encountered: