[Catalyst] working with strange port setups

[Alexander Hartmaier]

Please talk to your firewall admins (I'm one myself) to allow tcp/443.
I can't think of a reason they would deny that request.

Everything else is just sick and might hurt you later if an IPS tries to
verify that its http and can't decode it.

--
Best regards, Alex


Am Samstag, den 21.08.2010, 11:51 +0200 schrieb Darren Duncan:
> Hello,
>
> For context, I'm currently deploying/demoing a Catalyst app on a client machine
> where it uses a contrived base url scheme to work around a restrictive firewall
> setup.  To be specific, the Firewall blocks all ports except port 80 (plus a few
> admin ports like SSH etc) and I want to run through HTTPS, so I've currently got
> the machine's Apache running HTTPS through port 80 rather than 443.
>
> (My development machine isn't contrived at all, so no issue there.)
>
> The contrived url for my Catalyst app looks like this:
>
>    https://example.com:80/MyApp/some/page
>
> My app initially works fine here using the FastCGI or CGI server script and the
> urls produced by uri_for() are mostly what is needed here but not quite.
>
> An invocation of:
>
>    https://example.com:80/MyApp/some/page
>
> ... would have page urls going to the likes of:
>
>    https://example.com/MyApp/other/page
>
> ... which is correct except for the missing :80, because the result alone
> implies port 443 which isn't correct here.
>
> Now from running the first url with "?dump_info=1" shows that the FastCGI/CGI
> program, namely Catalyst, *does* receive the necessary information to produce
> correct base urls.
>
> Here's a relevant subset of "Request" details from dump_info:
>
> bless({
>    base => bless(do{\(my $o = "https://example.com/MyApp/")}, "URI::https"),
>    headers => bless({
>                          "host" => "example.com:80",
>                          "https" => "on",
>                        }, "HTTP::Headers"),
>    uri => bless(do{\(my $o =
> "https://example.com/MyApp/some/page?dump_info=1")}, "URI::https"),
> }, "Catalyst::Request")
>
> The "base" and "uri" reflect the incorrect output, but the "headers" records the
> fact that both port 80 was invoked and https is on.  Using the latter 2 bits of
> information, Catalyst should be able to construct "https://example.com:80" urls.
>
> Therefore, can anyone tell me how to configure Catalyst so that it builds the
> urls I need, or alternately where in the Catalyst source I should look in order
> to create a patch to enable this?
>
> Ideally this added smarts could make it into a CPAN release, if code changes are
> needed, but I would like to have this working quite soon, so if I knew what to
> patch in the meantime to get this to work, I would appreciate it.
>
> Undoubtedly, Catalyst should simply handle this situation, but I'm not surprised
> that it doesn't yet, considering this is an edge case that the developers may
> not have encountered before.
>
> Thank you. -- Darren Duncan
>
> _______________________________________________
> List: Catalyst at 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/


*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH   Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*