Justin Erenkrantz wrote:
>
> On Fri, Jun 21, 2002 at 04:02:52PM -0400, Greg Ames wrote:
> > I think this change to
> > ap_discard_request_body would work:
> >
> > --- modules/http/http_protocol.c19 Jun 2002 18:43:28 - 1.440
> > +++ modules/http/http_protocol.c21 Jun 2002
On Fri, Jun 21, 2002 at 04:02:52PM -0400, Greg Ames wrote:
> Justin Erenkrantz wrote:
>
> > Only where ap_status_drops_connection is true. The problem before
> > was that if you got a 404 and then got a 413 on the discard, it
> > would revert the status to a 404 and then try to read the body as
Justin Erenkrantz wrote:
> Only where ap_status_drops_connection is true. The problem before
> was that if you got a 404 and then got a 413 on the discard, it
> would revert the status to a 404 and then try to read the body as
> part of the handlers in serving the error page.
>
> We simply can
On Thu, Jun 20, 2002 at 05:30:52PM -0400, Greg Ames wrote:
> No sir. That's just one way to cause recursive errors. The code in ap_die that
> detects and prevents infinite recursive errors was written for a reason. If we
> cripple it, Apache becomes less robust.
No, this isn't stopping all rec
Greg Ames wrote:
> We ought to be able to have our cake and eat it too.
What about this?
Index: modules/http/http_request.c
===
RCS file: /home/cvs/httpd-2.0/modules/http/http_request.c,v
retrieving revision 1.148
diff -u -d -b -
On Thu, Jun 20, 2002 at 05:30:52PM -0400, Greg Ames wrote:
> We ought to be able to have our cake and eat it too. It is easy to turn off
> keepalives based on the original "type" passed to ap_die. I think you're saying
> there's now a dependency that r->status matches the original "type" on exit
Justin Erenkrantz wrote:
>
> On Thu, Jun 20, 2002 at 04:08:38PM -0400, Greg Ames wrote:
> > We cannot tolerate infinite recursion if an ErrorDocument gets an error. The if
> > statement I changed is how we detect this sort of recursive error. Please take
> > a look at the backtrace I posted to
On Thu, Jun 20, 2002 at 04:08:38PM -0400, Greg Ames wrote:
> We cannot tolerate infinite recursion if an ErrorDocument gets an error. The if
> statement I changed is how we detect this sort of recursive error. Please take
> a look at the backtrace I posted to [EMAIL PROTECTED], under the subject
Justin Erenkrantz wrote:
>
> On Thu, Jun 20, 2002 at 03:41:51PM -0400, Cliff Woolley wrote:
> >
> > Somebody remind me why that ap_status_drops_conn call was added in the
> > first place? It was a recent change, and seemed important at the time.
>
> Woah, woah, woah. Please revert.
>
> If the
On Thu, Jun 20, 2002 at 03:41:51PM -0400, Cliff Woolley wrote:
>
> Somebody remind me why that ap_status_drops_conn call was added in the
> first place? It was a recent change, and seemed important at the time.
Woah, woah, woah. Please revert.
If the status results in a dropped connection, we
On Thu, Jun 20, 2002 at 03:41:51PM -0400, Cliff Woolley wrote:
>
> Somebody remind me why that ap_status_drops_conn call was added in the
> first place? It was a recent change, and seemed important at the time.
I think it was so that we can drop the connection on certain error
conditions immedi
Somebody remind me why that ap_status_drops_conn call was added in the
first place? It was a recent change, and seemed important at the time.
--Cliff
On 20 Jun 2002 [EMAIL PROTECTED] wrote:
> gregames2002/06/20 12:34:29
>
> Modified:modules/http http_request.c
> Log:
> preven
On Sat, 27 Apr 2002 23:45:42 -0700, Justin Erenkrantz wrote:
>On Sun, Apr 28, 2002 at 06:41:35AM -, [EMAIL PROTECTED] wrote:
>> jerenkrantz02/04/27 23:41:35
>>
>> Modified:.CHANGES
>>modules/http http_request.c
>> Log:
>> If a subreq added a filter (say
On Sun, Apr 28, 2002 at 06:41:35AM -, [EMAIL PROTECTED] wrote:
> jerenkrantz02/04/27 23:41:35
>
> Modified:.CHANGES
>modules/http http_request.c
> Log:
> If a subreq added a filter (say INCLUDES) and the subreq was promoted via
> fast_redirect, the filt
> On Tue, Mar 05, 2002 at 05:41:28AM -, [EMAIL PROTECTED] wrote:
> > rbb 02/03/04 21:41:28
> >
> > Modified:modules/http http_request.c
> > Log:
> > Remove another hack from the server. The add_required_filters
> function
> > was required to make sure that the sub request
On Tue, Mar 05, 2002 at 05:41:28AM -, [EMAIL PROTECTED] wrote:
> rbb 02/03/04 21:41:28
>
> Modified:modules/http http_request.c
> Log:
> Remove another hack from the server. The add_required_filters function
> was required to make sure that the sub request had the correct
16 matches
Mail list logo
