protocol/1837: POSTing to script requiring authentication hangs if error 401 doc contains certain SSIs

[Derek Bruneau <de...@tripod.com>]

>Number:         1837
>Category:       protocol
>Synopsis:       POSTing to script requiring authentication hangs if error 401 doc contains certain SSIs
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Wed Feb 18 19:30:00 PST 1998
>Last-Modified:
>Originator:     derek@tripod.com
>Organization:
apache
>Release:        1.2.5
>Environment:
SunOS 5.5.1 Generic_103640-08 sun4u sparc SUNW,Ultra-1
Using gcc; tested bug under Netscape 3.01 and MSIE 4.0.
>Description:
When POSTing to a script requiring authentication, the request hangs if the
error 401 document contains two or more SSIs that are handled by
default_handler().  In our case, we have a server-parsed error401.html document
that uses the "include virtual" directive to incorporate two other documents,
neither of which is of a file type that has an assigned handler.

I think the problem is that each SSI creates a subrequest that calls
should_client_block() within discard_request_body(); both calls return true,
but the main request does not keep track of what the subrequests have done to
the request body.  As a result, when the second subrequest is created from the
main request's request_rec, the server tries to get rid of the POST's request
body a second time.  When this happens, the read on the connection fails to
find the expected bytes, which were consumed during the first subrequest.
(The other factor in this bug is the fact that the main request does not discard
the request body itself.)  Or so it seems...
>How-To-Repeat:
Create an error 401 document with two SSIs for odd file types (.tmplt, .js,
etc.) that will fall through to the default handler.  Then set up a POST to a 
script that needs authentication; the connection should hang while trying to
handle the second SSI in the error 401 doc.
>Fix:
I looked at the patch in PR#1399, but that doesn't seem to fix this problem
because the main request for the error 401 document satisfies is_HTTP_ERROR();
should_client_block() then returns 0, and the request body is not read.

My thought is to add a little more logic to the first line of
should_client_block():

  if (r->read_length || is_HTTP_ERROR(r->status)
    || (r->main && is_HTTP_ERROR(r->main->status))
    return 0;

So neither the main request of an error document nor any subrequests thereof
will satisfy should_client_block().

But I haven't tested this thoroughly.  I'm not all that familiar with the core,
and I don't know if this screws up somewhere other than the case I'm looking at.
As a non-code solution, assigning handlers for all file types used in SSIs
should also get around the problem
>Audit-Trail:
>Unformatted:
[In order for any reply to be added to the PR database, ]
[you need to include <ap...@Apache.Org> in the Cc line ]
[and leave the subject line UNCHANGED.  This is not done]
[automatically because of the potential for mail loops. ]