Comments (21)
@nhooyr Any further updates or progress on this?
from websocket.
So unfortunately, there is no clean way for a client to detect whether a HTTP server supports WebSockets over HTTP/2 without actually performing a handshake. I've emailed the working group regarding this.
from websocket.
I'm full time on websocket the next few months. There hasn't been any movement on the Go issue but I think I'll just fork net/http and implement my proposal linked above there. Then people can use my fork if they want WebSockets over http/2 with my library.
As well I'll open a CL on the standard library with my proposal so hopefully my fork won't be necessary. These things don't tend to get moving on issue trackers unless someone shows the initiative by implementing and demonstrating the demand.
from websocket.
See my proposal at golang/go#32763 (comment) to make net/http transparently handle http/2 upgrades server side and client side.
Would be much nicer than implementing it here as all Go WebSocket server's would work over HTTP/2 and we would get client side support for free as we use net/http's Client directly.
from websocket.
Hi, I have been building a similar websocket package, and would be willing to help if I can. Some things I can share:
- I also looked into the problem of identifying whether an endpoint supports HTTP/2 WebSockets. The best I came up with was similar to that suggested elsewhere - use an HTTP/2 connection first, then downgrade to HTTP/1 if necessary. However,
SETTINGS_ENABLE_CONNECT_PROTOCOL
, and similar host-wide mechanisms are not actually sufficient to identify whether an endpoint supports RFC8441 or not - I think it can be theoretically confused by a non-RFC8441 service behind an RFC8441-compliant reverse proxy. In reality, once this gets pushed out into the world a lot of services are likely to have partial support during an upgrade period - with some endpoints using the upgraded websocket packages and others not yet supporting it. The most foolproof way I came up with is to send a request and check for a 405 Method Not Allowed status code. Any RFC6455-compliant server will return a 405 Method Not Allowed if it recieves an unrecognized method, such asCONNECT
as used here. When I checked, all implementations I found did this correctly. - The
rw body for successful HTTP/2 Connect requests
has already been implemented. I have tested it out, and it works. - I did open an issue which you linked about being able to set the
:protocol
header. I have been looking into that, and so far I have not come up with any reasonable way to expose this behavior beyond adding an override hack like the one currently used to force HTTP/1 for websockets.
I see you on some of the related threads, so some of this is just to provide context to anyone else reading this issue thread.
from websocket.
Hi... is there a workaround that can be used until go supports something in that direction?
from websocket.
I believe the link was meant to be #402
from websocket.
Definitely worth reading https://tools.ietf.org/html/rfc8441
from websocket.
This does mean we cannot expose net.Conn directly as part of the API interface like gorilla/ws because there may not be a net.Conn to expose.
from websocket.
Hopefully shows up on https://lists.w3.org/Archives/Public/ietf-http-wg/2019AprJun/
from websocket.
https://lists.w3.org/Archives/Public/ietf-http-wg/2019AprJun/0010.html
from websocket.
So it looks like my suggestion won't be implemented. The only way to implement this then is to take a HTTP2 flag on the dial options or keep a global cache.
For the server, I'm sure we can do this transparently but will require some collaboration with net/http.
from websocket.
Related:
from websocket.
Could probably implement this reasonably quickly if we forked x/net/http2.
- Need to be able to advertise support for HTTP/2 WebSockets
- Use http.Hijacker on HTTP/2 Connect requests with a mocked out net.Conn for the stream.
- Have *http.Client return a rw body for successful HTTP/2 Connect requests
- Be able to set the
:protocol
pseduo header.
from websocket.
The rw body for successful HTTP/2 Connect requests has already been implemented. I have tested it out, and it works.
Nice.
However, SETTINGS_ENABLE_CONNECT_PROTOCOL, and similar host-wide mechanisms are not actually sufficient to identify whether an endpoint supports RFC8441 or not - I think it can be theoretically confused by a non-RFC8441 service behind an RFC8441-compliant reverse proxy.
I think it should be fine. A RFC 8441-complaint reverse proxy would translate HTTP/2 over web sockets into HTTP/1.1 for the origin server. e.g. Nginx translates all HTTP/2 requests into HTTP/1.1 for origin servers. Otherwise it wouldn't be RFC 8441-complaint if it just proxied the request directly.
I did open an issue which you linked about being able to set the :protocol header. I have been looking into that, and so far I have not come up with any reasonable way to expose this behavior beyond adding an override hack like the one currently used to force HTTP/1 for websockets.
Yea that is unfortunate. Maybe a new field on *http.Request
to set custom pseudo headers forcing HTTP/2? Or translating the HTTP/1.1 Protocol header to :protocol
for HTTP/2? I think that would be reasonable.
Hi, I have been building a similar websocket package, and would be willing to help if I can.
Awesome, would love your help :)
So then the remaining items here are:
- HTTP/2 CONNECT support for http.Handler
- Setting custom HTTP/2 pseudo headers
from websocket.
@hons82 Unfortunately apart from forking the go net/http library nope. I don't think it'd be very difficult to implement but there just hasn't been a response from the Go team on the linked issue.
from websocket.
Have you seen golang/go#49918?
from websocket.
Also golang/go#53209 and golang/go#53208.
from websocket.
Nope, I missed those thanks for the links!
from websocket.
That would be awesome
from websocket.
While the Go team decides how (or whether?) to handle this, is there a workaround ?
My execution environment:
- server: go1.21.4 darwin/arm64
- client: Safari 17.1 running a wasm client compiled with go1.21.4 (GOOS=js GOARCH=wasm)
When the wasm client tries to connect, the server gets this error from websocket.Accept(w,req,nil)
:
failed to accept WebSocket connection: WebSocket protocol violation: Connection header "keep-alive" does not contain Upgrade
When package websocket is compiled for wasm, the field websocket.DialOptions.HTTPHeader
is not available, so I cannot add the required header. This appears to be a limitation of the Javascript WebSocket API, or of how the API is used.
I presume this is all related to issue 373.
But it is possible that I am on the wrong track and have no idea what I am doing wrong.
I would be grateful for any guidance.
from websocket.
Related Issues (20)
- all goroutines are dead asleep - deadlock! wasm docs HOT 8
- Deadlocks due to CloseRead HOT 6
- Can't activate CORS for examples /chat/ HOT 2
- Reader() can only read one message, but Read() can read all messages HOT 5
- Error: panic: unaligned 64-bit atomic operation on arm32-bit while establishing websocket connection HOT 2
- Invalid readme example HOT 3
- Goroutine spike when closing connections in v1.8.10 (regression) HOT 3
- Transmit only single frame in Write when compression enabled too HOT 6
- Data race on `Conn.closeErr` HOT 3
- websocket.Conn.CloseNow() panics in WaitGroup.Wait HOT 2
- failed to get reader: use of closed network connection HOT 3
- Inline part of the full examples HOT 7
- Add custom ping message option to Ping function HOT 1
- failed to WebSocket dial: response body is not a io.ReadWriteCloser: io.nopCloserWriterTo HOT 1
- unsupported permessage-deflate parameter: "client_max_window_bits=15" from client HOT 8
- Update docs and mention explicit close required change in v1.8.11 HOT 16
- panic: sync: WaitGroup is reused before previous Wait has returned HOT 1
- Return net.ErrClosed from Read methods when connection is closed by us HOT 6
- failed: Close received after close HOT 6
- Document wsjson.Read closes the connection with the appropriate close status and error message if bad JSON is read
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from websocket.