Add builder for additional header values #400
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This would be great to simulate a connection from a browser ! @ManevilleF I've made a PR on your repo ManevilleF#1 |
daniel-abramov
requested changes
Jan 25, 2024
Doc correct to pass the CI
|
@ManevilleF I'v made PR once again on your repo to correct doc (once again 😅) and add a test Link to the PR: ManevilleF#2 Maybe after you merged it @daniel-abramov could merge this one! |
Corrections and add test
Merged
|
Nice. Btw, one of the CI steps fails. I did not check it in a detail, but my first guess is that the new example might require enabling some features. |
|
Thanks for the tip ! @ManevilleF If you add at the top of the test file I guess it should work ? |
daniel-abramov
approved these changes
Feb 12, 2024
Closed
emilk
added a commit
to rerun-io/ewebsock
that referenced
this pull request
Oct 10, 2024
Hello, In the native app, the Websocket protocol can lead to error because it doesn't act like the web interface. When we are using the WebSocket API (in the browser), it add automatically some headers - like the `Origin` header. In fact this header is mandatory, as explained in the RFC : - <https://datatracker.ietf.org/doc/html/rfc6455> ```text 8. The request MUST include a header field with the name |Origin| [[RFC6454](https://datatracker.ietf.org/doc/html/rfc6454)] if the request is coming from a browser client. If the connection is from a non-browser client, the request MAY include this header field if the semantics of that client match the use-case described here for browser clients. The value of this header field is the ASCII serialization of origin of the context in which the code establishing the connection is running. See [[RFC6454](https://datatracker.ietf.org/doc/html/rfc6454)] for the details of how this header field value is constructed. ``` However, if we don't set the `Origin` header in the native app, the app "could" not act the same as in the browser In this PR, I had the Origin header to the client. Note that - the PR to add a header in tungstenite is quite new : snapview/tungstenite-rs#400 - a new version of tungstenite has not been released yet (so this PR is kind of a draft) Thanks --------- Co-authored-by: Emil Ernerfeldt <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Work done
Added a
ClientRequestBuildertype inspired by websockets to allow for additional header values in the request, like authorization or subprotocols.The way I implemented this is not the cleanest but I wanted to avoid any breaking change.
This is merely a proposal, so feedback welcome !