Does System.Net.Http.HttpClient support sending a GET request with an entity body?

Question

I'm developing a Windows Phone 8 app that consumes a web service. This particular web service requires a GET request with an entity body.

I'm using the System.Net.Http.HttpClient to send this request, which I've successfully used to send various other web requests (GETs, POSTs, and PUTs). This is the first GET request that includes a payload and therefore includes a Content-Type and Content-Length header.

The request fails with an exception like the following:

'TaskHost.exe' (CLR C:\windows\system32\coreclr.dll: Silverlight AppDomain): Loaded 'C:\windows\system32\en-US\mscorlib.debug.resources.dll'. Module was built without symbols. An exception of type 'System.Net.ProtocolViolationException' occurred in System.Windows.ni.dll and wasn't handled before a managed/native boundary A first chance exception of type 'System.Net.ProtocolViolationException' occurred in mscorlib.ni.dll An exception of type 'System.Net.ProtocolViolationException' occurred in mscorlib.ni.dll and wasn't handled before a managed/native boundary

Including a payload with a GET request is a bit unusual although according to my research, not expressly forbidden by the RFCs.

I don't have the option of changing the web service. Does System.Net.Http.HttpClient outright not allow a GET with an entity body? If not, are there any work-arounds?

Thank you.

Answer 1

I know it's a while since you asked this but here goes anyway.

While sending a payload in the body of a GET request may not violate the RFC's client-side, it does go against common practice. What the RFC's do say is that a server fielding such a request is in no way obliged to look at anything other than the request URI and the Host: header in order to determine what its response should be.

Quoting from the HTTP 1.1 specification in RFC2616, section 5.2 says: "The exact resource identified by an Internet request is determined by examining both the Request-URI and the Host header field." It says nothing about a request body.

This means that, even if what you're attempting to do is not in violation of any RFC, the web service consumed by your WP8 app is. If you have no option but to use it then it's looking like you're going to have to roll out your own HTTP-ish client, which I'm guessing you've probably already done by now. The off-the-shelf solution in System.Net.Http.HttpClient isn't going to exhibit behaviour that will never be of use while communicating with a compliant server.