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

[Max Lapshin]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20121124/95f32a4c/attachment.htm>