httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sterling <sterl...@covalent.net>
Subject Re: 2_0_28 tarballs rolled and available
Date Tue, 13 Nov 2001 07:52:52 GMT
Hrm -

No one ever said beta was bug free.  but to me, beta should generally work
as expected out of the box.  If I were to be standing behind a piece
of software as beta, I sure as hell would give 'a rats ass' about
bugs that are fairly likely, and are not easy for the configurator to
triage and fix - adding auth to <Location /> is not an edge case - it is
probabably a very likely scenario.... especially when we have a fix.

anyhoo - I'm pretty sure I understand what beta means - but a serious bug
like that posted to the list with *no* response sent up a little red flag
- so I raised it publicly.

As far as your suggested patch  - why is that better (and don't say
performance wise - with all the string comparisons going on in a request
a small while loop in an error case won't affect that much)?  Really, we
want to ensure that the filters are added to the last request (since those are the
filters that are going to be called).  Sure, either patch fixes the bug
though -

sterling

On Mon, 12 Nov 2001, Justin Erenkrantz wrote:

> On Mon, Nov 12, 2001 at 10:59:14PM -0800, sterling wrote:
> > Hi -
> >
> > I still have an outstanding bug (and patch) that hasn't gotten a response.
> > I consider it a showstopper.  Given the current default config simply add
> > a <Location /> stanza with auth enabled and that triggers the bug I
> > reported previously (the one where headers filters are never called).
>
> Try this patch on for size (my tree is non-buildable since I synced
> up).  The thing here is that we walk up the request tree when we see
> a non-HTTP_OK code.  So, if we were to save the request_rec* BEFORE
> we walk up the tree, I think we end up with the correct request_rec
> and save some time to boot.
>
> > There is a workaround - to disable the ErrorDocument stuff - but still, it
> > seems to me like it should at least be double checked before 'beta'.
>
> FWIW, the only thing I see stopping a beta is a segfault.  Anything
> else, I don't give a rats ass about.  =)  And, *especially* if there
> is a workaround.  Because at this point, 2.0.29-dev is
> non-buildable, so I think it is unlikely we can get 2.0.29 out in
> a reasonable time-frame.  Remember, beta != bug-free.  -- justin
>
> Index: modules/http/http_request.c
> ===================================================================
> RCS file: /home/cvs/httpd-2.0/modules/http/http_request.c,v
> retrieving revision 1.118
> diff -u -r1.118 http_request.c
> --- modules/http/http_request.c	2001/11/11 22:31:03	1.118
> +++ modules/http/http_request.c	2001/11/13 06:10:41
> @@ -123,6 +123,11 @@
>      int error_index = ap_index_of_response(type);
>      char *custom_response = ap_response_code_string(r, error_index);
>      int recursive_error = 0;
> +    /* There are some cases where we walk up the request hierarchy
> +     * to obtain the original error, but when adding the required_filters,
> +     * we need to do so against the one we came in with.  So, save it.
> +     */
> +    request_rec *cur = r;
>
>      if (type == AP_FILTER_ERROR) {
>          return;
> @@ -223,7 +229,7 @@
>                          custom_response);
>          }
>      }
> -    add_required_filters(r);
> +    add_required_filters(cur);
>      ap_send_error_response(r, recursive_error);
>  }
>
>
>



Mime
View raw message