view release on metacpan or  search on metacpan

README  view on Meta::CPAN

DESCRIPTION
    This module is a Moose::Role which allows you more flexibility in your
    application's deployment configurations when deployed behind a proxy.

    The problem is that there is no standard way for a proxy to tell a
    backend server what the original URI for the request was, or if the
    request was initially SSL. (Yes, I do know about "X-Forwarded-Host", but
    they don't do enough)

    This creates an issue for someone wanting to deploy the same cluster of
    application servers behind various URI endpoints.

    Using this module, the request base ("$c->req->base") is replaced with
    the contents of the "X-Request-Base" header, which is expected to be a
    full URI, for example:

        http://example.com
        https://example.com
        http://other.example.com:81/foo/bar/yourapp

    This value will then be used as the base for uris constructed by

lib/Catalyst/TraitFor/Request/ProxyBase.pm  view on Meta::CPAN

This module is a L<Moose::Role> which allows you more flexibility in your
application's deployment configurations when deployed behind a proxy.

The problem is that there is no standard way for a proxy to tell a backend
server what the original URI for the request was, or if the request was
initially SSL. (Yes, I do know about C<< X-Forwarded-Host >>, but they don't
do enough)

This creates an issue for someone wanting to deploy the same cluster of
application servers behind various URI endpoints.

Using this module, the request base (C<< $c->req->base >>)
is replaced with the contents of the C<< X-Request-Base >> header,
which is expected to be a full URI, for example:

    http://example.com
    https://example.com
    http://other.example.com:81/foo/bar/yourapp

This value will then be used as the base for uris constructed by