https + large-file sending, sometimes fails

Gábor Farkas gabor at
Mon Dec 17 18:38:07 MSK 2007

Igor Sysoev wrote:
> On Mon, Dec 17, 2007 at 03:56:39PM +0100, G??bor Farkas wrote:
>> Igor Sysoev wrote:
>>> On Mon, Dec 17, 2007 at 03:12:33PM +0100, G?bor Farkas wrote:
>>>> i am sending large (400mb) csv files using nginx, using https.
>>>> sometimes not the whole file is served by nginx.
>>>> it simply closes the connection before the whole file is sent.
>>>> if the downloader supports resuming, then the file-download can be 
>>>> resumed.
>>>> the file is served using the "X-Accel-Redirect" technique (it's 
>>>> authenticated on a proxied apache server, and then the file is served 
>>>> directly by nginx)
>>>> when such problems happen, the error-log contains this:
>>>> 2007/12/17 01:02:03 [crit] 21821#0: *864836 SSL_write() failed (SSL: 
>>>> error:1409F07F:SSL routines:SSL3_WRITE_PENDING:bad write retry) while 
>>>> sending response to client, client:, server:, 
>>>> URL: "/some/url/to/a.csv", upstream: 
>>>> "http://internal-ip/some/auth/url/a.csv", host: ""
>>>> debian lenny (it has nginx 0.5.30-1)
>>>> any ideas why is this happening?
>>> Could you create debug log of this request (you may not use
>>> X-Accel-Redirect for this) ?
>> btw. now i reproduced the problem also without using "X-AccelRedirect".
>> one note: the whole thing (nginx itself, log-files, 
>> data-files-to-be-served) are on NFS. could that be a problem?
>> regarding debug log output: you mean by using something like:
>> events {
>>     debug_connection;
>>     }
>> ?
> Yes.
>> i will try, but it generates VERY large debug-log-files. is there 
>> perhaps a way how to make those debug-files smaller?
> No, but probably I need the last 2000 lines only.


ok, attached.

please note, that i made several "changes" to the file:

1. i only took the lines that had the same "*number" text. i assume this 
is what defines the steps in the same 'request', but i might be wrong.

2. i had to remove references to host-names, ip-addresses, etc.

but i hope this data is enough to determine the problem.

if not, i can also clean-up the "complete" debug-log, and put it 
somewhere online.

-------------- next part --------------
A non-text attachment was scrubbed...
Type: application/zip
Size: 8552 bytes
Desc: not available
URL: <>

More information about the nginx mailing list