Question

I have a Perl Dancer web application that uses GD to dynamically create images. I am trying to deliver these images to the user as PNG. For example:

package MyApp;
use Dancer ':syntax';
use GD;
...
get '/dynamic_image/:var1/:var2' => sub {
   my $im = GD::Image->new(100,100);
   my $black = $im->colorAllocate(0,0,0);
   my $white = $im->colorAllocate(255,255,255);
   $im->rectangle(10,10,90,90,$white);
   my $png = $im->png;
   return send_file( \$png, content_type => 'image/png', filename => params->{var1}."_".params->{var2}.".png" );
};

However, when accessing the above route, Chrome and Firefox don't seem to know what to do with the image data. If I try to use the route in Lightbox, Chrome complains. For example, when clicking on a link like this:

<a href="/dynamic_image/my/image" rel="lightbox">link</a>

Chrome's console says:

Resource interpreted as Image but transferred with MIME type application/octet-stream: "http://www.example.com/dynamic_image/my/image".

It looks like Dancer is not using content_type correctly. Interestingly, IE8 seems to load the images just fine. Any idea what's going on? I'm currently running it standalone on Windows 7 with Strawberry Perl v5.16.2.

Was it helpful?

Solution 3

After banging my head against this for awhile, I think I can answer my own question. Firefox actually tipped me off to a bug in my own code. Basically, when accessing the dynamically created image in Firefox, it would display a page with the HTTP request info along with the PNG data. I noticed that some debugging text was displayed on the page. It turns out that I left a print in one of the loops that generated the image data (I had used it to verify the image was being built correctly), and that text somehow made it into the "image" itself--which I assume caused Firefox and Chrome to freak out a bit. So this wasn't a Dancer or application bug, but a PEBKAC issue. Thanks for the input, everybody.

OTHER TIPS

To explain the different behavior with IE: If IE encounters a Content-Type of application/octet-stream, it will attempt to scan the file to determine a more specific MIME type. That behavior is covered more here.

I recommend using the GET` commandline tool from Perl's LWP distribution to confirm what's going on. You can try this:

GET -sSe http://www.example.com/dynamic_image/my/image | less

The result should include among other things the Content-Type header. It sounds like you'll find that it says application/octet-stream. This starts to look like an issue with Dancer.

You didn't specify what version of Dancer you are using. Older versions did not support the content_type option to send_file(). If you are are reading the latest docs on CPAN and expecting them to apply to an older version, there could be some confusion.

It does not seem to be a dancer problem. There are other environments where it happens too. Resource interpreted as Document but transferred with MIME type image

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top