On Fri, Jun 26, 2020 at 12:30 PM Ruediger Pluem <[email protected]> wrote:
>
> On 6/26/20 12:01 PM, Yann Ylavic wrote:
> > On Fri, Jun 26, 2020 at 8:57 AM Ruediger Pluem <[email protected]> wrote:
> >>
> >> On 6/25/20 2:16 PM, Yann Ylavic wrote:
> >>> On Thu, Jun 25, 2020 at 1:27 PM Ruediger Pluem <[email protected]> wrote:
> >>>>
> >>>> On 6/25/20 12:13 PM, Yann Ylavic wrote:
> >>>>> Index: modules/proxy/mod_proxy.c
> >>>>> ===================================================================
> >>>>> --- modules/proxy/mod_proxy.c (revision 1879145)
> >>>>> +++ modules/proxy/mod_proxy.c (working copy)
> >>>>
> >>>>> @@ -987,10 +991,10 @@ PROXY_DECLARE(int) ap_proxy_trans_match(request_re
> >>>>>                        "URI path '%s' matches proxy handler '%s'", 
> >>>>> r->uri,
> >>>>>                        found);
> >>>>>
> >>>>> -        return OK;
> >>>>> +        return servlet ? DONE : OK;
> >>>>
> >>>> Why setting it to DONE in the servlet case? Wouldn't that cause 
> >>>> ap_process_request_internal to be left early?
> >>>
> >>> No, ap_process_request_internal() would just skip r->uri decoding (we
> >>> are in pre_trans hook here, since mapping=servlet only happens there).
> >>> Anyway, it's an orthogonal change sorry, maybe we still want uri
> >>> decoding for directory/location walk in the servlet case, but since
> >>> this patch actually modifies r->uri (while other proxy mappings do
> >>> not), I thought it could be the final transformation (that's DONE
> >>> returned from pre_trans).
> >>
> >> Sorry, but I am still struggling: This is from server/request.c starting 
> >> line 233
> >>
> >> 233        access_status = ap_run_pre_translate_name(r);
> >> 234        if (access_status != OK && access_status != DECLINED) {
> >> 235            return access_status;
> >> 236        }
> >
> > Ah yes sorry, I missed you were referring to this initial commit.
> > It was later changed (http://svn.apache.org/r1879137) like this:
>
> Sorry my bad :-(. I missed to svn up my working copy when trying to 
> understand the attached patch,
> hence the questions. With r1879137 I am fine. Sorry for the noise.

Thanks, r1879235.


Regards;
Yann.

Reply via email to