Nobody have replied to you yet.<div><br></div><div>It is a very strange issue. Show your full reply headers. Do you have Content-Length in them?<span></span><br><br>On Wednesday, November 21, 2012, Alec Mocatta  wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've got a simple http server running, with gen_tcp options as follows:<br><br>
[<br><span style="white-space:pre-wrap">  </span>binary,<br><span style="white-space:pre-wrap">       </span>{active, false},<br><span style="white-space:pre-wrap">      </span>{packet, http_bin},<br><span style="white-space:pre-wrap">   </span>{reuseaddr, true},<br>




<span style="white-space:pre-wrap">     </span>{keepalive, true},<br><span style="white-space:pre-wrap">    </span>{delay_send, false},<br><span style="white-space:pre-wrap">  </span>{nodelay, true}<br>]<br><br>With
 one response in particular that sends a single 300000 byte http chunk 
with a single gen_tcp:send call, I'm seeing some clients failing to 
receive it, or only receiving the first 150000 - 250000 bytes.<br>

<br>Firefox, Chrome and Cocoa's NSURLConnection all have problems while 
receiving the response, with Firefox and NSURLConnection truncating the 
response, and Chrome not accepting it at all and giving an error. Curl 
and wget however receive the response fine.<br>

<br>tcpick -C -yP "tcp port 80" shows the connection being closed before
 all the data's sent, printing the data truncated at the same place as 
Firefox, followed by:<br>1      FIN-WAIT-2     x.108.161.x:65438 > 10.144.11.241:http<br>

1      TIME-WAIT      x.108.161.x:65438 > 10.144.11.241:http<br>1      CLOSED         x.108.161.x:65438 > 10.144.11.241:http<br><br>Setting sndbuf to 512000 however seems to solve the problem, at least for the 300000 byte chunk size I'm sending.<br>




<br>Why would sndbuf affect the validity of the TCP/HTTP stream? Someone
 suggested this looks like the return value of write(2) isn't being 
checked, or EAGAIN isn't being dealt with correctly? gen_tcp:send is 
returning ok, however.<br>
<br>
Erlang version: Erlang R15B02 (erts-5.9.2) [source] [64-bit] [async-threads:0] [hipe] [kernel-poll:true]<br><br>Any ideas what could be causing this?<br><br>Thanks,<br><br>Alec 
</blockquote></div>