[erlang-questions] Why does having SNDBUF too low break HTTP?

Dmitry Kolesnikov <>
Sat Nov 24 09:52:04 CET 2012


Hello,

Could you please share HTTP headers for request and response?

- Dmitry

On Nov 24, 2012, at 2:09 AM, Max Lapshin <> wrote:

> Nobody have replied to you yet.
> 
> It is a very strange issue. Show your full reply headers. Do you have Content-Length in them?
> 
> On Wednesday, November 21, 2012, Alec Mocatta wrote:
> I've got a simple http server running, with gen_tcp options as follows:
> 
> [
> 	binary,
> 	{active, false},
> 	{packet, http_bin},
> 	{reuseaddr, true},
> 	{keepalive, true},
> 	{delay_send, false},
> 	{nodelay, true}
> ]
> 
> 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.
> 
> 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.
> 
> 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:
> 1      FIN-WAIT-2     x.108.161.x:65438 > 10.144.11.241:http
> 1      TIME-WAIT      x.108.161.x:65438 > 10.144.11.241:http
> 1      CLOSED         x.108.161.x:65438 > 10.144.11.241:http
> 
> Setting sndbuf to 512000 however seems to solve the problem, at least for the 300000 byte chunk size I'm sending.
> 
> 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.
> 
> Erlang version: Erlang R15B02 (erts-5.9.2) [source] [64-bit] [async-threads:0] [hipe] [kernel-poll:true]
> 
> Any ideas what could be causing this?
> 
> Thanks,
> 
> Alec
> _______________________________________________
> erlang-questions mailing list
> 
> http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20121124/7feae31d/attachment.html>


More information about the erlang-questions mailing list