I can't reproduce this.  This test case is actually tested for in the
test suite.  Which SSL library are you using?  I was going off of the
assumption that the ap_discard_request_body() changes had broken this,
but since I have the most up-to-date code, I don't believe that the two
are related.

Please make sure that your code is up to date, because the server is
supposed to have logic that protects us from getting into an infinite
loop.

Wait a sec, the problem could be the ErrorDocument path.  The test suite
doesn't exercise that path.........  Will report back soon.

Ryan

----------------------------------------------
Ryan Bloom                  [EMAIL PROTECTED]
645 Howard St.              [EMAIL PROTECTED]
San Francisco, CA 

> -----Original Message-----
> From: Ryan Bloom [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 10, 2002 2:55 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Recursive error processing.
> 
> > From: Paul J. Reder [mailto:[EMAIL PROTECTED]]
> >
> > While Allan Edwards and I were doing some testing of SSL we ran into
a
> > case
> > where we were able to send Apache into an infinite loop which
> eventually
> > consumed the machine's resources.
> >
> > The problem occurs if you send a request to
> "http://some.where.com:443";
> > (instead
> > of "https://some.where.com:443";.
> 
> This was working a few days ago, and is in fact a part of the test
> suite.
> 
> > The problem seems to be related to the fact that ap_die should be
> killing
> > the custom_response and just dropping the connection (which is what
> 1.3
> > does)
> > rather than falling through and trying to send a custom response via
> > internal_redirect.
> 
> 1.3 doesn't drop the connection, it sends a custom response.
> 
> > Is this an artifact of the recent changes for 401/413 processing? Is
> this
> > symptomatic
> > of a bigger problem of infinite loops during error redirects?
> >
> > This all starts because the SSL post_read_request hook function
> > (ssl_hook_ReadReq)
> > returns HTTP_BAD_REQUEST after finding sslconn->non_ssl_request set
to
> 1
> > (by
> > ssl_io_filter_input after it notices ssl_connect fails in
> > ssl_hook_process_connection).
> 
> Hold on, I think I know what the problem is, I'll try to commit a fix
in
> a few minutes.
> 
> Ryan
> 


Reply via email to