https + large-file sending, sometimes fails

[Gábor Farkas]

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: 1.2.3.4, server: www.example.com, 
>>>> URL: "/some/url/to/a.csv", upstream: 
>>>> "http://internal-ip/some/auth/url/a.csv", host: "www.example.com"
>>>>
>>>> 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 127.0.0.1;
>>     }
>> ?
> 
> 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.
> 
> 

hi,

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.

thanks,
gabor
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clean.zip
Type: application/zip
Size: 8552 bytes
Desc: not available
URL: <http://nginx.org/pipermail/nginx/attachments/20071217/6f310ead/attachment.zip>