Justin Erenkrantz | 1 Jun 01:40 2002
Picon

Discarding bodies multiple times

On Fri, May 31, 2002 at 02:21:52PM -0700, Ryan Bloom wrote:
> Without this fix, the entire test suite fails, because the HTTP_IN
> filter is sending requests with 0 Content-Length to the
> CORE_INPUT_FILTER to read the body.  This means that every request times
> out after some timeout.  It has nothing to do with Jeff's problem,
> because EVERY test was taking forever.  I did run the test-suite, so if
> this breaks anything, there is no test for it.

Well, it's any request where ap_discard_request_body() is called
more than once.  In the case of apache/404.t, default_handler calls
ap_discard_request_body() and then ap_die() calls it too.

I'm not terribly sure if this sequence is valid.  Why is
default_handler discarding the body if it can't handle the
request?  Shouldn't we only discard the body right before we
send the response?  

Or, we could add an eos_gotten to request_rec to indiciate
that the input filters have received EOS so that
discard_request_body won't be re-entrant.  I dunno.  -- justin

Ryan Bloom | 1 Jun 02:14 2002
Picon

RE: Discarding bodies multiple times

> From: Justin Erenkrantz [mailto:jerenkrantz <at> apache.org]
> 
> On Fri, May 31, 2002 at 02:21:52PM -0700, Ryan Bloom wrote:
> > Without this fix, the entire test suite fails, because the HTTP_IN
> > filter is sending requests with 0 Content-Length to the
> > CORE_INPUT_FILTER to read the body.  This means that every request
times
> > out after some timeout.  It has nothing to do with Jeff's problem,
> > because EVERY test was taking forever.  I did run the test-suite, so
if
> > this breaks anything, there is no test for it.
> 
> Well, it's any request where ap_discard_request_body() is called
> more than once.  In the case of apache/404.t, default_handler calls
> ap_discard_request_body() and then ap_die() calls it too.
> 
> I'm not terribly sure if this sequence is valid.  Why is
> default_handler discarding the body if it can't handle the
> request?  Shouldn't we only discard the body right before we
> send the response?

The default handler discards the body, because it can't handle a body.
The assumption is that if the request gets to default_handler, then no
body will be allowed.  There are only two options as I see it.  1)  Keep
a record of having received an EOS in the request_rec.  2)  Only call
ap_discard_request_body if the default_handler will succeed.

Ryan
> 
> Or, we could add an eos_gotten to request_rec to indiciate
(Continue reading)

Cliff Woolley | 1 Jun 03:09 2002

RE: Discarding bodies multiple times

On Fri, 31 May 2002, Ryan Bloom wrote:

> The default handler discards the body, because it can't handle a body.
> The assumption is that if the request gets to default_handler, then no
> body will be allowed.  There are only two options as I see it.  1)  Keep
> a record of having received an EOS in the request_rec.  2)  Only call
> ap_discard_request_body if the default_handler will succeed.

You two are agreeing.. it's scaring me.  ;)

As for option #2... it seems cleaner, but can't a filter call ap_die()?
What then?

--Cliff

William A. Rowe, Jr. | 1 Jun 16:10 2002
Picon

Re: SSL Error in Head

Just a thought... make sure you are using the very same *.dll's for ssleay32
and libeay32 ... perhaps they are different.  Also make sure you use the very
same build flags (NO_WHATEVER) for mod_ssl.dsp that you use when you
build openssl.  See httpd.apache.org/docs-2.0/platform/win_compiling.html
for my comments.

"unexpected error" makes me ask if things just aren't out of sync, before
even digging in.  I'll check mozilla RC1 again and bump to RC3.  BTW - there
is no unpatched XP box in the mix, is there?

Bill

At 02:27 AM 6/1/2002, Jerry Baker wrote:
>I'm getting SSL errors with Mozilla 1.0RC3. Netscape 4.79 and IE6 appear
>to work ok.
>
>SSL Library Error: 336151538 error:140943F2:SSL
>routines:SSL3_READ_BYTES:sslv3 alert unexpected message
>
>Any ideas?
>
>--
>Jerry Baker

Ryan Bloom | 1 Jun 02:50 2002
Picon

RE: Discarding bodies multiple times

> From: Cliff Woolley [mailto:jwoolley <at> virginia.edu]
> 
> On Fri, 31 May 2002, Ryan Bloom wrote:
> 
> > The default handler discards the body, because it can't handle a
body.
> > The assumption is that if the request gets to default_handler, then
no
> > body will be allowed.  There are only two options as I see it.  1)
Keep
> > a record of having received an EOS in the request_rec.  2)  Only
call
> > ap_discard_request_body if the default_handler will succeed.
> 
> You two are agreeing.. it's scaring me.  ;)
> 
> As for option #2... it seems cleaner, but can't a filter call
ap_die()?
> What then?

A filter should NEVER call ap_die.  At the very worst, it should create
an error bucket and send it down the stack.

Ryan

Jerry Baker | 1 Jun 18:49 2002
Picon

Re: SSL Error in Head

"William A. Rowe, Jr." wrote:
> 
> Just a thought... make sure you are using the very same *.dll's for ssleay32
> and libeay32 ... perhaps they are different.  Also make sure you use the very
> same build flags (NO_WHATEVER) for mod_ssl.dsp that you use when you
> build openssl.  See httpd.apache.org/docs-2.0/platform/win_compiling.html
> for my comments.

No different dll's or flags.

> "unexpected error" makes me ask if things just aren't out of sync, before
> even digging in.  I'll check mozilla RC1 again and bump to RC3.  BTW - there
> is no unpatched XP box in the mix, is there?

Yes. I thought the XP thing was an error with chunking. Anyways, IE6
works fine and it does HTTP 1.1 also.

> 
> At 02:27 AM 6/1/2002, Jerry Baker wrote:
> >I'm getting SSL errors with Mozilla 1.0RC3. Netscape 4.79 and IE6 appear
> >to work ok.
> >
> >SSL Library Error: 336151538 error:140943F2:SSL
> >routines:SSL3_READ_BYTES:sslv3 alert unexpected message
> >
> >Any ideas?
> >

--

-- 
Jerry Baker
(Continue reading)

Jerry Baker | 1 Jun 18:58 2002
Picon

Re: SSL Error in Head

Jerry Baker wrote:
> 
> "William A. Rowe, Jr." wrote:
> >
> > Just a thought... make sure you are using the very same *.dll's for ssleay32
> > and libeay32 ... perhaps they are different.  Also make sure you use the very
> > same build flags (NO_WHATEVER) for mod_ssl.dsp that you use when you
> > build openssl.  See httpd.apache.org/docs-2.0/platform/win_compiling.html
> > for my comments.
> 
> No different dll's or flags.
> 
> > "unexpected error" makes me ask if things just aren't out of sync, before
> > even digging in.  I'll check mozilla RC1 again and bump to RC3.  BTW - there
> > is no unpatched XP box in the mix, is there?
> 
> Yes. I thought the XP thing was an error with chunking. Anyways, IE6
> works fine and it does HTTP 1.1 also.

Let me rephrase that. IE6 works most of the time, but the errors I do
see in IE6 do not prompt error messages to pop up in the browser, nor do
they cause entries in the error log. The IE6 errors are see under SSL
are things like images only loading halfway and the access log shows a
206 for those images.

The Mozilla error caused a pop-up alert from Mozilla itself that said
the server sent an unexpected value. The error log contained what I sent
here.

--

-- 
(Continue reading)

William A. Rowe, Jr. | 1 Jun 19:03 2002
Picon

Re: SSL Error in Head

At 11:49 AM 6/1/2002, you wrote:
>"William A. Rowe, Jr." wrote:
> >
> > "unexpected error" makes me ask if things just aren't out of sync, before
> > even digging in.  I'll check mozilla RC1 again and bump to RC3.  BTW - 
> there
> > is no unpatched XP box in the mix, is there?
>
>Yes. I thought the XP thing was an error with chunking. Anyways, IE6
>works fine and it does HTTP 1.1 also.

Cool.  The XP thing is very specific to EXACTLY how the application or the
server daemon uses windows sockets, in combination with significant data
exchange [e.g. http GET might not trigger it, while either http POST or SSL
negotiation might.  In fact, POST+SSL seems like the most lethal combination
when sockets are used in a BSD-like mode.]

I'd suggest applying the afd.sys fix first to the server, then to the 
client, and
testing out an unpatched XP Mozilla 1.0RC3 client against a patched XP
httpd server [we know Apache/httpd has this issue.]  If the bug remains for
the client on an unpatched XP box, it's definately worth bringing to the 
attention
of the Mozilla folks.  This could also expedite adopting the patch with XP 
SP1,
if it isn't already scheduled for inclusion and the window is still open.

Bill

(Continue reading)

Cliff Woolley | 1 Jun 19:14 2002

RE: Discarding bodies multiple times

On Fri, 31 May 2002, Ryan Bloom wrote:

> A filter should NEVER call ap_die.  At the very worst, it should create
> an error bucket and send it down the stack.

What about ap_http_header_filter() at line 1460 of http_protocol.c?

    APR_BRIGADE_FOREACH(e, b) {
        if (e->type == &ap_bucket_type_error) {
            ap_bucket_error *eb = e->data;

            ap_die(eb->status, r);
            return AP_FILTER_ERROR;
        }
    }

Is that an exception to that rule?  (I did a grep for ap_die and this was
the only case of it being used in a filter... but I knew about this one
when I sent my original message because I ran into this one just the other
day.)

--Cliff

Justin Erenkrantz | 2 Jun 00:53 2002
Picon

Re: Discarding bodies multiple times

On Sat, Jun 01, 2002 at 01:14:39PM -0400, Cliff Woolley wrote:
> On Fri, 31 May 2002, Ryan Bloom wrote:
> 
> > A filter should NEVER call ap_die.  At the very worst, it should create
> > an error bucket and send it down the stack.
> 
> What about ap_http_header_filter() at line 1460 of http_protocol.c?
>
<snip>
> 
> Is that an exception to that rule?

IMHO, yes.  ap_http_header_filter() is the guy who eats the error
buckets and figures out what to do with it - in this case - call
ap_die().  -- justin


Gmane