osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: t/modules/buffer.t failing in 2.4.36, LWP bug [Was: [VOTE] Release httpd-2.4.36]




On 2018/10/14 11:33:08, Rainer Jung <r...@xxxxxxxxxxx> wrote:
> Am 13.10.2018 um 11:46 schrieb Rainer Jung:>
> > Am 11.10.2018 um 20:55 schrieb Ruediger Pluem:>
> >>>
> >>>
> >> On 10/11/2018 08:10 PM, Christophe JAILLET wrote:>
> >>> No issue on my Ubuntu 18.04 VM.>
> >>>>
> >>> On what configuration are you running your tests, Rüdiger? macOS, >
> >>> just like Jim?>
> >>>
> >> Centos 7.5 64 Bit>
> >>>
> >> Regards>
> >>>
> >> Rüdiger>
> > >
> > The test fails for me as well for 2.4.36 on SLES12. Small bodies are OK, >
> > large not. The limit is somewhere between 1.3 and 1.5 MB, not always the >
> > same. The test hangs there until mod_reqtimeout times out after a >
> > minute, complaining that it could not read more data from the client. If >
> > I reduce the multiplicator 1000000 to eg. 200000 it always passes.>
> > >
> > If I start the test server using "t/TEST -start-httpd" and then use curl >
> > to POST data, I can even POST much bigger data and get the correct >
> > result back. I use>
> > >
> >   curl -v --data-binary @BIGFILE >
> > http://localhost:8529/apache/buffer_in/ > response-body>
> > >
> > So I assume it is a problem of interaction between the server reading >
> > the POST body and the client sending it.>
> > >
> > My test framework was freshly assembled recently, so lots of current >
> > modules.>
> > >
> > The setup is based on OpenSSL 1.1.1 in the server and in the test >
> > framework, but the actual test runs over http, so I don't expect any >
> > OpenSSL related reason for the failure.>
>
> I did some more tests including using LWP directly and sniffing the >
> packets on the network plus with mod_dumpio and also doing truss / strace.>
>
> I can reproduce even when sending using LWP directly or just the POST >
> binary coming with LWP. I can not reproduce with curl.>
>
> With mod_dumpio and in a network sniff plus truss it looks like the >
> client simply stops sending once it got the first response bytes. LWP >
> seems to select the socket FD for read and write. As long as only write >
> gets signalled, it happily sends data. Once it gets write plus read >
> signalled, it switches over to read and no longer checks for write. >
> Since our server side implementation is streaming and starts to send the >
> reflected bytes right away, this LWP behavior breaks the request.>
>
> I opened an issue under>
>
> https://github.com/libwww-perl/libwww-perl/issues/299>
>
> I don't know how to work around this in the test suite. If we had an >
> external curl or similar available it would work. Or if we would code >
> ourselves sending a raw request on the socket and reading the raw request.>
>
> Depending on timing the test could break even for small POST sizes. Eg. >
> on my Solaris system it already breaks around 128KB, but theoretically >
> it could happen even much earlier.>
>
> Regards,>
>
> Rainer>
>

This is an issue only with LWP? I thought you also detected browsers and curl failing with the test server as-configured?
--
Daniel Ruggeri