Community,

Is this issue that I'm struggling with really that large of a challenge?
If it is, that's fine, I'm trying to judge if it's something that I should
abandon or if it can be done at all..

Thanks,

HB

On Sun, Jun 10, 2018 at 9:23 PM, Herb Burnswell <herbert.burnsw...@gmail.com
> wrote:

> Thanks again Yann.
>
> >  I'm not sure to understand, you want the request to be without
> > "/frontpage" suffix between the browsers and the proxy (i.e.
> > https://vanity.example.com) and with the suffix added between proxy
> > and the backend (i.e. https://vanity.example.com/frontpage), right?
>
> You are correct, this is exactly the behavior I'm looking to configure,
> the backend application needs the /frontpage path but we don't want users
> to need to add it.  However, I wish I could say I'm making progress but I'm
> really not other than I have a better understanding of why it's failing.
>
> It does not matter if I append the /frontpage path to the end of the
> ProxyPath directive or the BalancerMember declarations.  Here is what
> happens:
>
> Without any Rewrite directive, the request is directed to the backend per
> the ProxyPath declaration as:
>
>  https://app(1|2|3).example.com:8443/frontpage
> <https://app1.example.com:8443/frontpage> using https://vanity.example.com
>
> The backend then sends a request for 'GET /frontpage/login.jsp' using the
> vanity URL and it again hits the proxy.  However, the proxy just goes back
> through the same direction and again appends the request using ProxyPass.
> It ends up looking like:
>
> https://vanity.example.com/frontpage/frontpage/login.jsp instead of the
> desired https://vanity.example.com/frontpage/login.jsp
>
> So, using the rewrite rule:
>
> RewriteRule "^/frontpage(.+)" "$1" [R,L]
>
> The initial page load works fine (it ends up being:
> https://vanity.example.com/login.jsp).  But any subsequent requests fail
> as they all begin with '/frontpage' as in:
>
> GET /frontpage/path/to/file
>
> And the rewrite rule again strips the '/frontpage' from the GET request
> and causes it to fail.
>
> I have to imagine there is a rewrite condition or conditions that will
> allow for the desired behavior to work but I'm just not experienced enough
> yet.
>
> I hope I have not completely confused the situation, any guidance is
> greatly appreciated as always..
>
> HB
>
>
>
> On Sun, Jun 10, 2018 at 12:31 PM, Yann Ylavic <ylavic....@gmail.com>
> wrote:
>
>> Hi HB,
>>
>> On Sun, Jun 10, 2018 at 5:05 PM, Herb Burnswell
>> <herbert.burnsw...@gmail.com> wrote:
>> >
>> > I need the proxy to work as: https://vanity.example.com
>> >
>> > I'm thinking this may require use of  RewriteCond directives, however I
>> may
>> > be going about this wrong.
>> >
>> > Is there a way to define an 'active' request to avoid looping through
>> the
>> > same ProxyPass or ProxyPassMatch needed for an initial request?
>>
>> I'm not sure to understand, you want the request to be without
>> "/frontpage" suffix between the browsers and the proxy (i.e.
>> https://vanity.example.com) and with the suffix added between proxy
>> and the backend (i.e. https://vanity.example.com/frontpage), right?
>>
>> If this is the case, maybe something like this then (the opposite
>> rewrite of what I've told you so far :p ):
>>     ProxyPass / balancer://applicationcluster/frontpage/ ...
>>     ProxyPassReverse / balancer://applicationcluster/frontpage/
>> You would then remove the "/frontpage" suffix from the BalancerMember
>> declarations.
>>
>> Since ProxyPass would do the rewrite from "/" => "/frontpage/", you
>> don't need mod_rewrite here.
>> There is no case where "/frontpage" (without the trailing '/') can
>> arrive on the backend side since ProxyPass will always start the
>> forwarded path with "/frontpage/", but I suppose "/frontpage" and
>> "/frontpage/" work equally on the backend no?
>>
>> Hope that helps..
>>
>> Regards,
>> Yann.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
>> For additional commands, e-mail: users-h...@httpd.apache.org
>>
>>
>

Reply via email to