C# – Set custom headers for websocket handshake in .NET 4.5

chttpnetwebsocket

I'm trying to set a WebSocket connection of C# client with third-party server. When I connect with JS client to the same server, it establishes connection and everything goes fine. C# client connects to the server, but for some unknown reason server responds with 500 code. Debugging with WireShark has shown that HTTP handshake phase of WebSocket connection differs between client implementation in a set of headers. I would like to tweak the headers default System.Net.WebSockets.ClientWebSocket class sends to the server to check that the issue is there. Though, I couldn't find a way to do that.

How do I instruct ClientWebSocket of some other class in that namespace to send additional given headers in handshake phase?

Best Answer

It looks like this is exposed by ClientWebSocketOptions.SetRequestHeader, so:

obj.Options.SetRequestHeader("foo", "bar");

should work. This also provides access to AddSubProtocol(...).

Related Solutions

C# – .NET String.Format() to add commas in thousands place for a number

String.Format("{0:n}", 1234);  // Output: 1,234.00
String.Format("{0:n0}", 9876); // No digits after the decimal point. Output: 9,876

Custom HTTP headers : naming conventions

The recommendation is was to start their name with "X-". E.g. X-Forwarded-For, X-Requested-With. This is also mentioned in a.o. section 5 of RFC 2047.

Update 1: On June 2011, the first IETF draft was posted to deprecate the recommendation of using the "X-" prefix for non-standard headers. The reason is that when non-standard headers prefixed with "X-" become standard, removing the "X-" prefix breaks backwards compatibility, forcing application protocols to support both names (E.g, x-gzip & gzip are now equivalent). So, the official recommendation is to just name them sensibly without the "X-" prefix.

Update 2: On June 2012, the deprecation of recommendation to use the "X-" prefix has become official as RFC 6648. Below are cites of relevance:

###3. Recommendations for Creators of New Parameters

...

SHOULD NOT prefix their parameter names with "X-" or similar constructs.

###4. Recommendations for Protocol Designers

...

SHOULD NOT prohibit parameters with an "X-" prefix or similar constructs from being registered.

MUST NOT stipulate that a parameter with an "X-" prefix or similar constructs needs to be understood as unstandardized.

MUST NOT stipulate that a parameter without an "X-" prefix or similar constructs needs to be understood as standardized.

Note that "SHOULD NOT" ("discouraged") is not the same as "MUST NOT" ("forbidden"), see also RFC 2119 for another spec on those keywords. In other words, you can keep using "X-" prefixed headers, but it's not officially recommended anymore and you may definitely not document them as if they are public standard.

Summary:

the official recommendation is to just name them sensibly without the "X-" prefix
you can keep using "X-" prefixed headers, but it's not officially recommended anymore and you may definitely not document them as if they are public standard

Best Answer

Related Solutions

C# – .NET String.Format() to add commas in thousands place for a number

Custom HTTP headers : naming conventions

Related Topic