.
Regards
Jiri Horky
On 10/17/2014 08:01 AM, Jiri Horky wrote:
> Hi Max,
>
> thanks for the explanation, I agree that from the traces, it really
> looks like there were no data available in the socket from the upstream,
> thus a different situation than I posted the first time
match and will get back to you.
Jirka H.
On 10/17/2014 06:58 AM, Maxim Dounin wrote:
> Hello!
>
> On Fri, Oct 17, 2014 at 12:48:43AM +0200, Jiri Horky wrote:
>
> [...]
>
>> 2014/10/17 00:41:55 [debug] 27396#0: *12485 connect to 1.1.1.1:,
>> fd:184 #12552
> He
14/10/17 00:41:55 [debug] 27396#0: *12485 SSL buf copy: 52
2014/10/17 00:41:55 [debug] 27396#0: *12485 SSL buf copy: 402
2014/10/17 00:41:55 [debug] 27396#0: *12485 SSL to write: 730
2014/10/17 00:41:55 [debug] 27396#0: *12485 SSL_write: 730
2014/10/17 00:41:55 [debug] 27396#0: *12485 http write fi
Hi Maxim,
here is the debug log of one failed connection:
2014/10/17 00:18:30 [debug] 25783#0: *8190 http keepalive handler
2014/10/17 00:18:30 [debug] 25783#0: *8190 malloc: 00BE44F0:1024
2014/10/17 00:18:30 [debug] 25783#0: *8190 SSL_read: 1024
2014/10/17 00:18:30 [debug] 25783#0: *8190
Hi,
thanks for the quick response. I tried it with nginx/1.7.6 but
unfortunately, the errors still show up. However, I did not try to
confirm that these were with the same trace, but I strongly suspect so.
I will confirm that hopefully tomorrow. Anything other I should try?
Regards
Jiri Horky
stream, so function:
1687 rc = u->process_header(r);
1688
should have had everything, i.e. complete header (verified in
wireshark), so it should never return NGX_AGAIN and thus reach the line
1670.
Any pointers will be much appreciated.
Regards
Jiri Horky
GET / HTTP/1.0
Host: my.u
