> -----Ursprüngliche Nachricht-----
> Von: Jim Jagielski
> Gesendet: Dienstag, 9. Dezember 2008 21:54
> An: [email protected]
> Betreff: Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
>
>
> On Dec 9, 2008, at 2:39 PM, Ruediger Pluem wrote:
>
> >
> >
> > On 12/09/2008 07:23 PM, Jim Jagielski wrote:
> >>
> >> On Dec 9, 2008, at 12:15 PM, Paul Querna wrote:
> >>
> >>> Ruediger Pluem wrote:
> >>>> On 12/09/2008 02:06 PM, Jim Jagielski wrote:
> >>>>> On Dec 8, 2008, at 7:43 PM, William A. Rowe, Jr. wrote:
> >>>>>
> >>>>>> Paul Querna wrote:
> >>>>>>> The change fixed velocity.apache.org, but broke
> www.apache.org.
> >>>>>>>
> >>>>>>> All of this sub-request + output filter stuff started
> in r620133
> >>>>>>> kinda
> >>>>>>> needs some more thought.
> >>>>>> My thought is that fast_internal_subrequest (which I last
> >>>>>> refactored, but
> >>>>>> was bogusly introduced for mod_negotiation) must die, now.
> >>>>>>
> >>>>>> Votes?
> >>>>>>
> >>>>> Can we simply revert r620133 (et.al.) and then start from *that*
> >>>>> point? That is, get to a known OK state and then boot
> >>>>> fast_internal_subrequest?
> >>>> Currently I would be more keen to know the issues we are still
> >>>> facing, so
> >>>> that we can keep these cases and issues in mind when we do a
> >>>> rewrite of
> >>>> this stuff.
> >>>
> >>> Applying the patch invsersed the working directoy indexes.
> >>>
> >>> velocity worked, but www.apache.org stopped working. Deflate was
> >>> loaded in both cases.
> >>>
> >>
> >> hmmm....
> >>
> >> r724805 cleans up a lot of framework breaks from r724515
> >>
> >> looking to be a positional issue...
> >
> > Hmmm, normally ap_remove_output_filter should be able to handle this
> > case. I guess this needs some investigation why it does not.
>
> Yeah... for me, that's the worrisome part. Will do some deeping
> tracing on the code path.
I think I know what happens. The problem is that we have not updated the
request_rec field in all filter structs at this point of time. So
ap_remove_output_filter
updates rr->output_filters instead of r->output_filters. The following patch
reverts r724805 and fixes the issue by moving the calls to update_r_in_filters
up in the code. I couldn't find any framework failures afterwards. Do you still
see some?
Index: modules/http/http_request.c
===================================================================
--- modules/http/http_request.c (revision 724941)
+++ modules/http/http_request.c (working copy)
@@ -518,6 +518,15 @@
r->output_filters = rr->output_filters;
r->input_filters = rr->input_filters;
+ /* If any filters pointed at the now-defunct rr, we must point them
+ * at our "new" instance of r. In particular, some of rr's structures
+ * will now be bogus (say rr->headers_out). If a filter tried to modify
+ * their f->r structure when it is pointing to rr, the real request_rec
+ * will not get updated. Fix that here.
+ */
+ update_r_in_filters(r->input_filters, rr, r);
+ update_r_in_filters(r->output_filters, rr, r);
+
if (r->main) {
ap_add_output_filter_handle(ap_subreq_core_filter_handle,
NULL, r, r->connection);
@@ -541,20 +550,8 @@
}
if (next && (next->frec == ap_subreq_core_filter_handle)) {
ap_remove_output_filter(next);
- if (next == r->output_filters) {
- r->output_filters = r->output_filters->next;
- }
}
}
-
- /* If any filters pointed at the now-defunct rr, we must point them
- * at our "new" instance of r. In particular, some of rr's structures
- * will now be bogus (say rr->headers_out). If a filter tried to modify
- * their f->r structure when it is pointing to rr, the real request_rec
- * will not get updated. Fix that here.
- */
- update_r_in_filters(r->input_filters, rr, r);
- update_r_in_filters(r->output_filters, rr, r);
}
AP_DECLARE(void) ap_internal_redirect(const char *new_uri, request_rec *r)
Regards
Rüdiger
