Phil Mitchell wrote:
For (a) documentation, I took a stab at writing some. If this looks
okay, I'll submit a patch ...
Heh, unified diffs are easier to read (at least to me) than scanning for
[ADDED].
That said, this looks good, please submit said patch :)
Thank you!
t0m
On Sat, Apr 25, 2009 at 11:13:16AM -0700, seasproc...@gmail.com wrote:
Yes, it all makes sense ... now. Still, I think that when something as
fundamental as $c-request-base is fragile, it calls for some thought.
Perhaps a config variable that lets you set your SSL port? My guess is that
the
On Mon, Apr 27, 2009 at 4:22 AM, Matt S Trout dbix-cl...@trout.me.ukwrote:
I think either (a) we need more documentation explaining exactly how it
makes its best guess so that it's more obvious to the people the guess is
wrong for what's happening, or (b) we need (a) and some better guessing.
On 26 Apr 2009, at 00:13, Bill Moseley wrote:
On Sat, Apr 25, 2009 at 04:23:50PM -0400, Hans Dieter Pearcey wrote:
On Sat, Apr 25, 2009 at 06:29:50AM -0700, Bill Moseley wrote:
The SSL decryption is happening on Apache and Apache is proxying the
request to Catalyst.
What? No it isn't.
On Fri, Apr 24, 2009 at 03:48:36PM -0700, Phil Mitchell wrote:
I am running mod_perl/Apache 2.0 and serving SSL on a non-standard port via
a VirtualHost. I thought my apache setup was vanilla, but perhaps not -- I
am no apache expert. It seems surprising to have to set an ENV variable in
On Sat, Apr 25, 2009 at 6:29 AM, Bill Moseley mose...@hank.org wrote:
On Fri, Apr 24, 2009 at 03:48:36PM -0700, Phil Mitchell wrote:
I am running mod_perl/Apache 2.0 and serving SSL on a non-standard port
via
a VirtualHost. I thought my apache setup was vanilla, but perhaps not --
I
On Sat, Apr 25, 2009 at 06:29:50AM -0700, Bill Moseley wrote:
The SSL decryption is happening on Apache and Apache is proxying the
request to Catalyst.
What? No it isn't. It's using mod_perl; there's no reverse proxying going on
from the config snippet pasted.
Also, this means that
On Sat, Apr 25, 2009 at 04:23:50PM -0400, Hans Dieter Pearcey wrote:
On Sat, Apr 25, 2009 at 06:29:50AM -0700, Bill Moseley wrote:
The SSL decryption is happening on Apache and Apache is proxying the
request to Catalyst.
What? No it isn't. It's using mod_perl; there's no reverse proxying
On Sat, Apr 25, 2009 at 1:23 PM, Hans Dieter Pearcey
hdp.perl.catalyst.us...@weftsoar.net wrote:
On Sat, Apr 25, 2009 at 06:29:50AM -0700, Bill Moseley wrote:
The SSL decryption is happening on Apache and Apache is proxying the
request to Catalyst.
What? No it isn't. It's using
On Sat, Apr 25, 2009 at 05:46:55PM -0700, seasproc...@gmail.com wrote:
Dear original poster: is Apache2::ModSSL installed?
No, it's not. Should it be? Other than to avoid this issue?
I have no idea; the code I pasted from Engine::Apache uses it as its preferred
method of determining
The expected behavior (for me) is that secure() returns true if the
connection is secured via SSL.
Looking at Engine::CGI, it appears that it only returns true if $ENV{HTTPS}
eq 'ON' or if you're on Port 443.
Furthermore, if secure fails because you're on a non-standard port and HTTPS
is not
On 24 Apr 2009, at 22:10, seasproc...@gmail.com wrote:
The expected behavior (for me) is that secure() returns true if the
connection is secured via SSL.
Looking at Engine::CGI, it appears that it only returns true if $ENV
{HTTPS} eq 'ON' or if you're on Port 443.
Furthermore, if secure
On Fri, Apr 24, 2009 at 2:22 PM, Tomas Doran bobtf...@bobtfish.net wrote:
On 24 Apr 2009, at 22:10, seasproc...@gmail.com wrote:
The expected behavior (for me) is that secure() returns true if the
connection is secured via SSL.
Looking at Engine::CGI, it appears that it only returns true
13 matches
Mail list logo
