FAQ
<mst> I've put something like that in a sub prepare before now
<mst> we should maybe have a config option to override base
<mst> patches would be welcome :)

Here's an attempt. I've never really hacked on the core before, so please go
easy. Also I know that POD isn't included, but that's because I can't figure
out where it belongs. I'll write it, given a place to put it.

Anyway, this is a patch to create a pair of config keys tell
Engine::CGI "ignore what the server thinks the base path is, and use these
instead". It's useful in the case that someone has their application
port-forwarded, load-balanced, proxied, etc. through some sort of device that
doesn't set X-Forwarded-Host.

How it works: If no config is provided, life continues as it always has. If
the request is HTTP and $c->config->{override_base_uri} is set, we use that
as $c->req->base. If the request is HTTPS and
$c->config->{override_base_uri_secure} is set, we use that as $c->req->base.
If the request is HTTPS and override_base_uri_secure isn't set, but
override_base_uri is, we use override_base_uri and switch its scheme to https
(hopefully it doesn't have a port).

Patch against Catalyst-Runtime/5.80/trunk which I hope is the right thing.

Comments appreciated,
Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: override-base-uri.diff
Type: text/x-diff
Size: 3254 bytes
Desc: not available
Url : http://lists.scsys.co.uk/pipermail/catalyst/attachments/20081009/7ed85dc1/override-base-uri.bin

Search Discussions

  • Tomas Doran at Oct 10, 2008 at 8:28 am

    On 10 Oct 2008, at 01:33, Andrew Rodland wrote:

    <mst> I've put something like that in a sub prepare before now
    <mst> we should maybe have a config option to override base
    <mst> patches would be welcome :)

    Anyway, this is a patch to create a pair of config keys tell
    Engine::CGI "ignore what the server thinks the base path is, and
    use these
    instead". It's useful in the case that someone has their application
    port-forwarded, load-balanced, proxied, etc. through some sort of
    device that
    doesn't set X-Forwarded-Host.
    Am I correct in thinking that this would be useful in cases other
    than when you're using the CGI engine? Shouldn't this patch be
    generally applicable to all engines? (Patching just the CGI engine
    would make it of somewhat limited use for most people I think)
    How it works: If no config is provided, life continues as it always
    has. If
    the request is HTTP and $c->config->{override_base_uri} is set, we
    use that
    as $c->req->base. If the request is HTTPS and
    $c->config->{override_base_uri_secure} is set, we use that as $c-
    req->base.
    If the request is HTTPS and override_base_uri_secure isn't set, but
    override_base_uri is, we use override_base_uri and switch its
    scheme to https
    (hopefully it doesn't have a port).
    What I specifically do, which I was hoping this patch would sort out
    for me - is that I unwrap SSL at a proxy layer, and then forward onto
    the application running on a non-secure port..

    I have a feeling however that with this patch, even if I specified a
    base_uri that was https://, if the server serving the application was
    http:// then line 95 of your patch would swap the scheme back to http
    for me :(

    (My current workaround is to nobble the C::Request::is_secure
    typeglob to sub { 1 } given a certain config key - not the most
    elegant solution)

    On that note - the same line (95) - wouldn't you be better swapping
    the scheme by calling a method on the URI object you generate, rather
    than using a regex?
    Patch against Catalyst-Runtime/5.80/trunk which I hope is the right
    thing.
    Yes :)

    Cheers
    t0m
  • Tomas Doran at Oct 10, 2008 at 8:36 am

    On 10 Oct 2008, at 08:28, Tomas Doran wrote:
    Am I correct in thinking that this would be useful in cases other
    than when you're using the CGI engine? Shouldn't this patch be
    generally applicable to all engines? (Patching just the CGI engine
    would make it of somewhat limited use for most people I think)
    As was just pointed out to me on #catalyst, all of the other engines
    inherit from C::Engine::CGI, so the above is all lies.

    Please ignore that paragraph. ;)

    Cheers
    t0m
  • Jason Kuri at Oct 10, 2008 at 7:21 pm
    Great work. I was looking into this yesterday. I'm glad you beat me
    to it. :-)

    To follow up on Tomas' comment - Why not make the override_base_uri /
    override_base_uri_secure include the schema? So if you want the URI's
    to include https:// even if the request is coming in not-secure, you
    can do that.

    Without this functionality it would be hard to do SSL accelerators and
    such properly.

    I'd also love a way to callback from uri_for - but that's another
    story and issue altogether.

    Jay
    On Oct 9, 2008, at 6:33 PM, Andrew Rodland wrote:

    <mst> I've put something like that in a sub prepare before now
    <mst> we should maybe have a config option to override base
    <mst> patches would be welcome :)

    Here's an attempt. I've never really hacked on the core before, so
    please go
    easy. Also I know that POD isn't included, but that's because I
    can't figure
    out where it belongs. I'll write it, given a place to put it.

    Anyway, this is a patch to create a pair of config keys tell
    Engine::CGI "ignore what the server thinks the base path is, and use
    these
    instead". It's useful in the case that someone has their application
    port-forwarded, load-balanced, proxied, etc. through some sort of
    device that
    doesn't set X-Forwarded-Host.

    How it works: If no config is provided, life continues as it always
    has. If
    the request is HTTP and $c->config->{override_base_uri} is set, we
    use that
    as $c->req->base. If the request is HTTPS and
    $c->config->{override_base_uri_secure} is set, we use that as $c-
    req->base.
    If the request is HTTPS and override_base_uri_secure isn't set, but
    override_base_uri is, we use override_base_uri and switch its scheme
    to https
    (hopefully it doesn't have a port).

    Patch against Catalyst-Runtime/5.80/trunk which I hope is the right
    thing.

    Comments appreciated,
    Andrew
    <override-base-
    uri.diff>_______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
  • Andrew Rodland at Oct 10, 2008 at 8:04 pm

    On Friday 10 October 2008 01:21:14 pm Jason Kuri wrote:
    Great work. I was looking into this yesterday. I'm glad you beat me
    to it. :-)

    To follow up on Tomas' comment - Why not make the override_base_uri /
    override_base_uri_secure include the schema? So if you want the URI's
    to include https:// even if the request is coming in not-secure, you
    can do that.

    Without this functionality it would be hard to do SSL accelerators and
    such properly.
    I was trying to be clever and make it so that you only needed one config key
    in the case where your secure and nonsecure bases only differed in the
    scheme. I guess it was too clever. I'll go back and make them entirely
    separate -- it'll be less code anyway. :)

    Andrew
  • Andrew Rodland at Oct 10, 2008 at 10:51 pm

    On Friday 10 October 2008 02:04:44 pm Andrew Rodland wrote:
    On Friday 10 October 2008 01:21:14 pm Jason Kuri wrote:
    Great work. I was looking into this yesterday. I'm glad you beat me
    to it. :-)

    To follow up on Tomas' comment - Why not make the override_base_uri /
    override_base_uri_secure include the schema? So if you want the URI's
    to include https:// even if the request is coming in not-secure, you
    can do that.

    Without this functionality it would be hard to do SSL accelerators and
    such properly.
    I was trying to be clever and make it so that you only needed one config
    key in the case where your secure and nonsecure bases only differed in the
    scheme. I guess it was too clever. I'll go back and make them entirely
    separate -- it'll be less code anyway. :)
    New version based on input from t0m and jayk and karpet.

    lib/Catalyst/Engine/CGI.pm | 23 +++++++--
    t/unit_engine_cgi.t | 86 +++++++++++++++++++++++++++++++++++
    2 files changed, 105 insertions(+), 4 deletions(-)

    Andrew
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: override-base-uri-2.diff
    Type: text/x-diff
    Size: 3601 bytes
    Desc: not available
    Url : http://lists.scsys.co.uk/pipermail/catalyst/attachments/20081010/b3659d1a/override-base-uri-2.bin
  • Ash Berlin at Oct 10, 2008 at 9:26 pm

    On 10 Oct 2008, at 19:21, Jason Kuri wrote:

    I'd also love a way to callback from uri_for - but that's another
    story and issue altogether.

    Jay

    Seen http://search.cpan.org/~rkitover/Catalyst-Plugin-SmartURI-0.029/lib/Catalyst/Plugin/SmartURI.pm
    ?

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedOct 10, '08 at 1:33a
activeOct 10, '08 at 10:51p
posts7
users4
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2022 Grokbase