Plack::Middleware::Debug with deflated content
oalders
I'm very new to Plack, so please excuse me if I've missed something
obvious.
I've just annoted the docs for Plack::Middleware::Debug.
http://www.annocpan.org/~MIYAGAWA/Plack-Middleware-Debug-0.09/lib/Plack/Middleware/Debug.pm#note_2542
Basically, I had been running a Catalyst app using the Compress::Gzip
and Compress::Deflate plugins. I couldn't for the life of me figure
out why the debug panels weren't appearing. I've figured it out now
and have temporarily removed the plugins in order to activate the
panels. I've added the AnnoCPAN note to clarify this.
I see that there is a Plack::Middleware::Deflater, which seems to be
the opposite of what might be required to get the debug panels to work
on deflated content. If I were to put something together to inflate
deflated content before manipulating it, is
Plack::Middleware::Deflater the correct template for something like
this? I guess the process would be something like:
detect deflated content -> inflate content -> re-deflate content -> do
something appropriate with content length headers
Any thoughts on the best way to go about this?
Thanks,
Olaf
Tatsuhiko Miyagawa
> Basically, I had been running a Catalyst app using the Compress::Gzip
> and Compress::Deflate plugins. I couldn't for the life of me figure
> out why the debug panels weren't appearing. I've figured it out now
> and have temporarily removed the plugins in order to activate the
> panels.
Yes, if you enable the deflate/gzip on the app side (Catalyst), the
content filtering middleware such as Debug cannot mangle the content.
> I see that there is a Plack::Middleware::Deflater, which seems to be
> the opposite of what might be required to get the debug panels to work
> on deflated content. If I were to put something together to inflate
> deflated content before manipulating it, is
> Plack::Middleware::Deflater the correct template for something like
> this? I guess the process would be something like:
>
> detect deflated content -> inflate content -> re-deflate content -> do
> something appropriate with content length headers
>
> Any thoughts on the best way to go about this?
It sounds like an overly complicated processing to gain nothing. When
you enable Debug you're obviously on the development, and enabling
gzip compression on the development doesn't make much sense.
On the other hand you can use Deflater middleeware *outside* Debug, so
your application gives uncompressed content, filtered with the Debug
panel and then Deflater to compress with the gzip encoding.
--
Tatsuhiko Miyagawa
Olaf Alders
>
>
>> I see that there is a Plack::Middleware::Deflater, which seems to be
>> the opposite of what might be required to get the debug panels to work
>> on deflated content. If I were to put something together to inflate
>> deflated content before manipulating it, is
>> Plack::Middleware::Deflater the correct template for something like
>> this? I guess the process would be something like:
>>
>> detect deflated content -> inflate content -> re-deflate content -> do
>> something appropriate with content length headers
>>
>> Any thoughts on the best way to go about this?
>
> It sounds like an overly complicated processing to gain nothing. When
> you enable Debug you're obviously on the development, and enabling
> gzip compression on the development doesn't make much sense.
>
> On the other hand you can use Deflater middleeware *outside* Debug, so
> your application gives uncompressed content, filtered with the Debug
> panel and then Deflater to compress with the gzip encoding.
I do agree with you on this. In this case, I probably need to do just that, but I do have another related issue. Take this code, for example:
...
use Plack::App::Proxy;
use Plack::Builder;
builder {
enable 'SimpleContentFilter', filter => sub {
s{</body>}{analytics code here</body>};
};
Plack::App::Proxy->new( remote => 'http://www.example.com/' )
->to_app;
};
...
First off, I have read the note about SimpleContentFilter being a demo. :) Now, this works very well for me when proxying a site which is not deflating content. However, if I try to proxy a site which is running Apache + mod_deflate, I can't mangle the content and the code just doesn't work.
The idea is that an ad agency wants to run some Google ads for a client using an exact replica of their current site, but with the phone number replaced (for tracking purposes) and also with some analytics code added to the body for more tracking. Proxying will solve this nicely, since I don't have to replicate all of the other site's functionality -- I only add a layer in between. It works beautifully for the first site I'm running this on, but if the sysadmin on the other end starts to compress outgoing text, then I've got a problem.
Olaf
Tatsuhiko Miyagawa
> I do agree with you on this. In this case, I probably need to do just that, but I do have another related issue. Take this code, for example:
>
> ...
> use Plack::App::Proxy;
>
> use Plack::Builder;
>
> builder {
> enable 'SimpleContentFilter', filter => sub {
> s{</body>}{analytics code here</body>};
> };
>
> Plack::App::Proxy->new( remote => 'http://www.example.com/' )
> ->to_app;
>
> };
> ...
>
> First off, I have read the note about SimpleContentFilter being a demo. :) Now, this works very well for me when proxying a site which is not deflating content. However, if I try to proxy a site which is running Apache + mod_deflate, I can't mangle the content and the code just doesn't work.
Hmm, you're right - if the remote site does gzip encoding, exactly
like your own Catalyst application using the gzip encoding plugin
installed, your content mangling middleware can't get to the raw text
content of the source. Well, maybe writing a middleware component that
inflates the content might make sense there, as you originally
suggested :)
--
Tatsuhiko Miyagawa