How to prevent packet fragmentation for a HttpWebRequest

Question

I am having a problem using HttpWebRequest against a HTTP daemon on an embedded device. The problem appears to be that there is enough of a delay between the http headers be

Answer 1

In the end the vendor pushed out a firmware upgrade that included a new version of HTTPD and the problem went away. They were using BusyBox linux, and apparently there was some other problem with the HTTPD implementation that they had suffered from.

In terms of my original question, I don't think there is any reliable way of doing it, apart from writing a socket proxy. Some of the workarounds I played with above worked by luck not design (because they meant .net sent the whole packet in one go).

Answer 2

Is your embedded server a HTTP/1.1 server? If so, try setting Expect100Continue=false on the webrequest before you call GetRequestStream(). This will ensure that the HTTP stack does not expect the "HTTP/1.1 100 continue" header response from the server, before sending the entity body. So, even though the packets will still be split between the header and body, the inter packet gap will be shorter.

Answer 3

Just looking at the client side splitting packets problem, I posted an answer to my own question which is linked to this one:

I saw the answer here:

http://us.generation-nt.com/answer/too-packets-httpwebrequest-help-23298102.html

Answer 4

What has seemed to have fixed it is disabling Nagling on the ServicePoint associated with that URI, and sending the request as HTTP 1.0 (neither on their own seem to fix it):

var servicePoint = ServicePointManager.FindServicePoint(uri.Uri);
servicePoint.UseNagleAlgorithm = false;

However this still seems to have fixed it only by making the request go out faster, rather than forcing the headers and payload to be written as one packet. So it could presumably fail on a loaded machine / high latency link etc.

Wonder how hard it would be to write a defragmenting proxy...