will trillich wrote on 2/21/11 5:50 PM:
> Okay -- we'd tried this approach using Chrome already, and it is not showing
> *any* http:// requests from the https:// page.
>
> Life HTTP Headers (FireFox) shows either https://server.name/path requests or
> server-relative /path requests. Period.
>
>
I'm pleased to announce Mason 2, the first major version of Mason in ten years:
http://search.cpan.org/perldoc?Mason
For those not familiar with it, Mason is a templating framework for generating
web pages and other dynamic content. Mason 2 has been rearchitected and
reimplemented from the
Okay -- we'd tried this approach using Chrome already, and it is not showing
*any* http:// requests from the https:// page.
Life HTTP Headers (FireFox) shows either https://server.name/path requests
or server-relative /path requests. Period.
Same url, yet internet explorer complains... I've got a
On Mon, 21 Feb 2011 15:15:17 +, Carl wrote:
> I recommend you try viewing the page in a browser that will let you
> see all network requests - e.g. firefox with the firebug plugin
> running.
Another nice tool is included in Chrom{e,ium} under Tools → Developer
Tools, where - if you load an ht
Not sure if someone's suggested this so far, but perhaps one of the resources
you're including using https: is getting a redirect back to a non-SSL URL?
- john romkey
http://www.romkey.com/
___
List: Catalyst@lists.scsys.co.uk
Listinfo:
Thanks for the cookie back-story, Carl. We're looking into a firefoxy
diagnosis.
On Mon, Feb 21, 2011 at 9:15 AM, Carl Franks wrote:
> On 21 February 2011 14:09, will trillich
> wrote:
> > Nope it's not the javascript. Searching view-source for "http://"; shows
> only
> > DOCTYPE, xmlns, and
2011/2/21 Oroszi, Róbert
> if you're using non-ssl javascript cdn you should embed javascript ( or css
> ) like this:
>
>
>
> "//" - its a protocolless javascript embedding technique :)
>
> good luck :)
>
IIRC, I tried this on a site a few years back and changed back --
unfortunately, for a rea
On 21 February 2011 14:09, will trillich wrote:
> Nope it's not the javascript. Searching view-source for "http://"; shows only
> DOCTYPE, xmlns, and links to other/external websites.
> The session cookie does show as non-secure, so that's why we're thinking
> it's the main culprit.
> Otherwise,
On Mon, Feb 21, 2011 at 6:11 AM, will trillich
wrote:
> That's a neat trick -- hadn't heard of that one before. But the javascript
> isn't our "nonsecure-items" problem.
Protocol free // isn't a javascript specific technique while we're on
it. It simply means use the protocol that's currently in
That's a neat trick -- hadn't heard of that one before. But the javascript
isn't our "nonsecure-items" problem.
2011/2/21 Oroszi, Róbert
> if you're using non-ssl javascript cdn you should embed javascript ( or css
> ) like this:
>
>
>
> "//" - its a protocolless javascript embedding technique
Nope it's not the javascript. Searching view-source for "http://"; shows only
DOCTYPE, xmlns, and links to other/external websites.
The session cookie does show as non-secure, so that's why we're thinking
it's the main culprit.
Otherwise, is there a tool out there that helps discover what Explor
if you're using non-ssl javascript cdn you should embed javascript ( or css
) like this:
"//" - its a protocolless javascript embedding technique :)
good luck :)
ps: it works with images, css, javascript too
2011/2/21 Jason Galea
> you're not using a non-ssl cdn for your javascript librarie
On Feb 21, 2011, at 3:43 PM, Hernan Lopes wrote:
> to configure your logs on catalyst and psgi, create your
> myapp/script/my_app.psgi correctly and tell it where to log, like this
But there is some logging Plack::Middleware from box:
SimpleLogger, NullLogger, LogDispatch, Log4perl.
They seems
to configure your logs on catalyst and psgi, create your
myapp/script/my_app.psgi correctly and tell it where to log, like this
#!/usr/bin/env perl
use strict;
use warnings;
use lib ( "./lib" );
use MyApp;
use Catalyst::Engine::PSGI;
use FCGI::ProcManager;
use Plack::Builder;
use Plack::Middlewar
Hello.
I trying to switch my Catalyst application from mod_perl to Plack.
But can't understand how to deal with stderr properly?
Warning from catalyst goes to stderr and Plack doesn't capture it
into psgi.errors, is it right behavour?
Now i use workaround: C::P::Log::Dispatch and C::P::LogWarnin
15 matches
Mail list logo