Added CustomHeaders to WebSocketClient #22
Conversation
|
Hello, there. Well, Your 'pull request' is similar to the issue #15. |
|
I added an "Authorization" header, which is proprietary to the app I'm working on. Someone didn't tell our server engineer that the WebSockets spec doesn't support custom headers :P |
|
websocket-sharp supports the HTTP Basic/Digest auth as a client. ws.SetCredentials ("name", "password", true); // 'true' if Basic authIs your "Authorization" header used for neither Basic or Digest auth? |
|
Nope, we have a proprietary format for the Authorization header. It consists of a keyword unique to the app, followed by a Base64 encoding of the user's credentials, followed by a Base64 encoding of the MD5 hash of a special string constructed from certain other HTTP headers... it's really a strange situation. |
|
I've understood your situation at your app. But, I don't plan to merge your 'pull request'. |
|
"I think i should support for each necessary header." — this is wrong in so many ways. You can't support every possible header. It's against HTTP nature. |
|
@maqdev Huh? What do you mean? Necessary means necessary for the WebSocket protocol defined in RFC 6455. I've never said to support Every HTTP header. |
|
RFC 6455 defines that Also it says that RFC 6455 doesn't restricts HTTP header possible values. And you can't strictly define what headers are necessary in a library designed for a public use. Sure you can do it as an author of this great library. But I'm also sure that it doesn't make this library better. |
|
sta, what do you suggest for those who need custom headers? to not use your library? |
|
First of all, i don't plan to support user defined custom header.
I suggest to use
I don't think so. The better, i mean, is to be more stable, and is not to be exaggerated specifications. So, i don't think it's better to be able to add custom header or any header undefined in RFC 6455.
And also, RFC 6455 doesn't describe to use every HTTP header. I (will) basically follow headers described in Section 1.3 of RFC 6455. But i will not follow undescribed HTTP headers in RFC 6455. |
|
"I suggest to use SetCookie instead of custom header." so... you claim that every possible WS server that requires custom headers from its clients is bad-designed - they all should use cookies... is it your thesis? ) |
|
Hmm,,, It's an exaggerated story.
That's just user defined custom matter, and it's not related to the WebSocket protocol spec. I think that to use cookie is better than to use custom header, because of closer to standard and easier. But this is my idea, i don't claim that it's best. |
|
It's an interpretation problem. ) WS spec claims that "custom headers are ALLOWED", and it seems you interpret the word "ALLOWED" as "NOT NECESSARY" (not necessary to support custom headers), but imho it should be interpreted as "WS library implementation SHOULD ALLOW custom headers". I think you'll agree that custom headers (in point of server-side developers' view) don't break any HTTP/WS rules and design guidelines - and no one can say that cookies are always better than custom headers. And now suppose we have 3rd-party WS server (we cannot modify it) and it requires some custom headers from clients. In this normal(!) case your library becomes useless - is it OK for you? |
Huh? Which section of RFC 6455 is it described in? |
|
In my scenario (the scenario that prompted me to make this pull request), I don't have any control over the server. The server expects a custom header and rejects my connection if it doesn't receive it. Cookies are not a workaround for this. I agree that it's generally bad form to require custom headers on the server-side, especially because the WebSocket API on browsers don't support this. But please don't punish client-side developers when server developers don't follow best practices. |
|
I'm in the exact same case as @dallonf. The headers are often application dependent, and it's not a bad practice to use custom headers in HTTP... It should be possible to specify any custom header in the handshake request. @sta, I don't understand your position; by refusing this feature, you're making your library useless to many people... |
|
@thomaslevesque My position is very clear. I follow RFC 6455. And RFC 6455 describes like the following in 4.1. Client Requirements:
Does your custom header have public document that defines that? |
|
I think we disagree on how the specification should be understood...
I think that part is quite clear and unambiguous; what comes after is just examples of headers that can be included, not an exhaustive list ("for example", "such as"). The way I read it, it clearly means that you can include any header you like. In any case, even if your interpretation of the specification were correct, for all practical purposes, support for custom headers is necessary; in many cases, the server will refuse the connection if they're not present, which makes this library unusable. As for me, I know that I can't use it in its current state; perhaps I'll fork it at some point, but for now I'm using WebSocket4Net instead. |
|
Emphasis mine:
|
|
I think:
And @dallonf wrote:
That's right. So, to add custom headers is weak for me, under the WebSocket spec. |
Nothing says these documents have to be public RFCs. They can be internal design documents that describe the application's API. And even if browsers don't support custom headers in the handshake request, the specification does say they're allowed, so it's not a valid argument against supporting them. |
How does many people see such INTERNAL design documents? Plz show me.
The WebSocket spec allows the headers that have accessible documents (such as RFCs) that define them, not custom headers. Which section of RFC 6455 is CUSTOM HEADER described in? |
|
RFC 6455 Section 1.2 (emphasis mine):
And here's a link to RFC2616 for reference; it's just the HTTP spec for headers (HTTP allows for pretty much any header). I'm curious why you are so opposed to this change. It's not a difficult improvement, it took me maybe 15 minutes to submit this pull request the first time (it would probably have to be done again, since the library has changed significantly since then and this PR now doesn't merge cleanly). It's not against the WebSocket spec to include arbitrary headers - at best, it's open for interpretation, which means it's a library's responsibility to enable as many use cases as possible. And the lack of this feature has prevented more than one developer (that is, everybody in this thread except for you) from using this library without forking it. I'm offering to make this library more useful for more people. All you have to do is click the Merge button. Is it that difficult? |
What I mean is that not all web APIs are public; a company might have a specific API that uses custom headers, and these headers would typically be described in the technical specifications of the API. That's what I meant by "internal": internal to the company. But actually, it could also be public documents that just happen not to be a RFC: for instance, if a website offers a public API that uses websockets, it might define custom headers that would be described in the API documentation. For instance, my company develops an app that uses a custom
They don't specifically mention "custom headers", but RFC 6455 very clearly says that "any other header fields" are allowed, which obviously includes custom headers. |
|
+1 Custom headers. There are many 3rd party APIs that require customs headers. Wish I read this sooner. |
|
+1 Custom headers. I need to send "X-Forwarded-For" to simulate a reverse proxy set up in front of my app, but I'm unable to do that with the current codebase. I could set up a reverse proxy, but this would make it easier for me to debug on my development machine. |
|
+1 Custom headers. This is to CONSUME web sockets, which definitely accepts any and all headers as per RFC and literally every single web socket server software in existence. Using this library does not change 3rd party proprietary servers to auto-magically read cookies instead of headers. This package would be used a lot more with custom headers. |
|
+100 for custom headers. It is required for a library such as this! Thanks btw for this library. I appreciate your time and everything. But, because ws protocol begins as an HTTP handshake, ws should support any and all HTTP(S) headers so that the handshake can be properly authorized or whatever. This should include all known and custom headers, so let the developers choose whatever they want (whitelisting headers would be impossible and pointless). There is no reason headers should be restricted. |
|
I need this because of the library I'm trying to connect to. I don't get a choice. They use Authorization bearer tokens. They don't use cookie. Literally impossible to integrate with their websocket without something like this. |
|
This is incorrect and borders on absurd. This library does not properly implement RFC 6455 as written. The document states:
It also states:
The referenced RFC, RFC 2616, is the "Hypertext Transfer Protocol -- HTTP/1.1" specification. That document defines the format of a
The format and parsing of a message header says NOTHING about it's contents. There is nothing in RFC 6455 that says the WebSocket library must process a header. Applications are allowed to create and process their own headers according to their own internal documents as they see fit. This library clearly DOES NOT fully conform to the specification as defined in RFC 6455 and is in violation of its intent. |
|
Socket library without custom headers is useless. 7k users are aready uses fork with custom headers. |
|
Yes, I need this feature too - for a test stub for a mobile app. |
|
For everyone who was on this thread: deniszykov is doing some amazing work with his WebSocket server/client. It's fast, scalable and has custom headers. https://github.com/deniszykov/WebSocketListener |
|
@Codeusa thanks, but this thread is about the websocket client, not server ;) |
|
@thomaslevesque the library features a WebSocket client. |
Ah, ok. Thanks! |
|
No customizable headers and no way to customize User Agent make this library completly unusable. Many sites restrict unknown user agents (connecting with "websocket-sharp/1.0" user agent is no-go), also many sites require custom authentication headers. If Microsoft had this kind of attitude they would remove methods to modify HTTP Headers in WebRequest and also hardcode ".net Framework" as enforced user agent string. I don't have to add how absurd that is. |
|
@sta I think this speaks for itself, enjoy people! https://www.nuget.org/packages/websocket-sharp-customheaders |
|
Hey, can we stop the strict adherence to RFC 6455 in December 2011? As a new generation of wonderful things come along (O Auth headers), I expected websocket sharp to have an add headers function.
|
|
@PathToLife this project is dead. Use the fork ;) |
|
So, i have readed this as a real novell =) |
|
Wow, here in 2020 and no custom headers have been implemented. Moving to the fork. Such a shame. |
|
Use .net ClientWebSocket. Refer setrequestheader |
|
I am definitely going to be using that fork - nice. |
|
https://github.com/felixhao28/websocket-sharp fork is 2606 commits behind, but people still prefer it 10 to 1 just over this one feature! This is a bad hill to die on. |
|
Has this been resolved? |
Still not resolved, and probably never will be. There are multiple wrappers for .net default ClientWebSocket use one of those. |
|
The fact this has not been resolved and implemented 11 years later is insane. How is that even possible?! |
|
It's possible because this library is dead. Everyone switched to the fork. |
First off, thanks so much for this library! I was previously using WebSocket4Net which apparently doesn't handle large messages correctly.
This change adds a
CustomHeadersproperty toWebSocketClientwhich will send additional HTTP headers on the handshake request. This isn't exactly per the WebSocket spec, but it was needed for a particular project and it could be useful for others as well.