On Sat, Jun 13, 2015 at 6:06 PM, Yann Ylavic <ylavic....@gmail.com> wrote:

> On Sat, Jun 13, 2015 at 6:51 PM, Rainer Jung <rainer.j...@kippdata.de>
> wrote:
> >
> > any chance you can reproduce the problem with a slightly patched 2.4.14
> to
> > get additional log output around the suspect code?
> >
> > The patch would be
> >
> > Index: modules/http/http_filters.c
> > ===================================================================
> > --- modules/http/http_filters.c (revision 1685283)
> > +++ modules/http/http_filters.c (working copy)
> > @@ -514,6 +514,9 @@
> >                      rv = parse_chunk_size(ctx, buffer, len,
> >
> > f->r->server->limit_req_fieldsize);
> >                      if (rv != APR_SUCCESS) {
> > +                        ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, f->r,
> > APLOGNO(99999)
> > +                                      "Error parsing chunk size, buffer
> > %*.*s, limit %d",
> > +                                      len, len, buffer,
> > f->r->server->limit_req_fieldsize);
> >                          if (rv != APR_ENOSPC) {
> >                              http_error = HTTP_BAD_REQUEST;
> >                          }
>
> Hmm, it seems that the backported patch in r1684515 is not the
> proposed/voted v5, where AH01590 would normally have been logged here.
> Bill, looks like v4 was applied instead... Attached is the diff on
> http_filter.c between the two patches.
>
> BTW, v5 does not address the regression encountered by Steffen either:
> space(s) between the chunk-size and the CRLF which are not allowed
> anymore.
> This is not really RFC compliant, but I guess we have to be lenient here...
>
> I did not look at pr12355.t and pr43738.t yet, however those passed in
> my tests, so it's probably something different.
>

Just in case it wasn't clear, these aren't regressions.  I get them with
prior releases on FreeBSD 10.1 also.

I don't know if it is the Perl stack or OpenSSL or ??? that results in the
consistent failure.  (This FreeBSD has a significantly newer Perl stack
from system packages than CentOS 7.)  IIUC, Rainer has been reporting
intermittent failures on various platforms for a while.



> Jeff, any idea where these failures can come from?
> What do -v and the logs say?
>

pr12355.t only:

# testing : renegotiation on POST works
# expected: 200
# received: 500
not ok 3
# testing : request body matches response
# expected: 'hello world'
# received: 'Status read failed:  at
/usr/local/lib/perl5/site_perl/Net/HTTP/Methods.pm line 289.
# '
not ok 4
...
# testing : renegotiation on POST works
# expected: 200
# received: 500
not ok 7
# testing : request body matches response
# expected: 'xxxxxx...
# received: 'Status read failed:  at
/usr/local/lib/perl5/site_perl/Net/HTTP/Methods.pm line 289.
# '
not ok 8

I think this is the underlying failure I'm seeing, possibly for both
testcases:

Sat Jun 13 23:08:55.005710 2015] [ssl:error] [pid 3745] [client
127.0.0.1:44064] AH02261: Re-negotiation handshake failed
[Sat Jun 13 23:08:55.005743 2015] [ssl:error] [pid 3745] SSL Library Error:
error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher -- Too
restrictive SSLCipherSuite or using DSA server certificate?



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Reply via email to