content type headers

[Dermot Paikkos]

Hi,

I've got some old code to deal with and I have hit a problem.

If there is a request for a page that has mixed content EG: 'text/html'
and 'image/jpeg', the image media is not being displayed correctly under
the FireFox browser.

The way things currently work is that media other than text/html is
output from a separate page, so you might have a bit of html that for an
image that looks like this:

<img src="/images/showImage.html?imageid=123456" alt="" />

Within showImage.html you have a 1) a piece of code that supposedly sets
the content_type to image/jpeg, and 2) calls to a function that
literally prints the image based on is CGI param 'imageid'.

In my experiments, IE is correctly identifying the media and Firefox is
not. However I think FF is expecting the content_type to be sent with
the media and IE is guess* based upon the media it receives.

So my question, initially, is can a request set the content_type more
than once?

Thanx,
Dp.

[Gunnar Hjalmarsson]

Dermot Paikkos wrote:
> If there is a request for a page that has mixed content EG: 'text/html'
> and 'image/jpeg', the image media is not being displayed correctly under
> the FireFox browser.

What exactly do you mean by that? When you use a browser to request a
usual HTML page with IMG elements, there are multiple subsequent
request/response pairs, one for each image. Could you post the source
code of a page that behaves as you say?

> The way things currently work is that media other than text/html is
> output from a separate page, so you might have a bit of html that for an
> image that looks like this:
>
> <img src="/images/showImage.html?imageid=123456" alt="" />
>
> Within showImage.html you have a 1) a piece of code that supposedly sets
> the content_type to image/jpeg, and 2) calls to a function that
> literally prints the image based on is CGI param 'imageid'.

As long as the images are accessible from the web, I do not see why you
would need to use a separate script like that.

> In my experiments, IE is correctly identifying the media and Firefox is
> not. However I think FF is expecting the content_type to be sent with
> the media and IE is guess* based upon the media it receives.

What if you simply try to view an image with FF directly?

http://www.example.com/images/someimage.jpg

If that's not displayed as expected, there may be something with the
configuration of your FF browser.

--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl

[Matthew Hellman]

>>Hi,
>>
>>I've got some old code to deal with and I have hit a problem.
>>
>>If there is a request for a page that has mixed content EG: 'text/html'
>>and 'image/jpeg', the image media is not being displayed correctly under
>>the FireFox browser.
>>
>>The way things currently work is that media other than text/html is
>>output from a separate page, so you might have a bit of html that for an
>>image that looks like this:
>>
>><img src="/images/showImage.html?imageid=123456" alt="" />
>>
>>Within showImage.html you have a 1) a piece of code that supposedly sets
>>the content_type to image/jpeg, and 2) calls to a function that
>>literally prints the image based on is CGI param 'imageid'.

This sounds fine, but it obviously isn't working right? For some examples, see: http://www.perlmonks.org/?node_id=18565

>>In my experiments, IE is correctly identifying the media and Firefox is
>>not. However I think FF is expecting the content_type to be sent with
>>the media and IE is guess* based upon the media it receives.

I believe this is correct. Regardless of the content-type header value, IE will take an educated guess. FF will not. This would jive with the behavior I would expect with an incorrect content-type header.

>>So my question, initially, is can a request set the content_type more
>>than once?

Sure, you can add 10 different content type headers if you want, each with different values. I have no idea what a given browser will do though;-) The answer to your problem seems to be making sure one and only one content-type header is returned with the image, and that it has the correct value (e.g. Content-Type: image/jpeg or whatever). It would help if you could use something like the FF liveHttpHeaders add-on and show us the actual HTTP headers in the response for the request "/images/showImage.html?imageid=123456".

-----Message Disclaimer-----

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to Con...@principal.com and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act ("E-Sign")
unless a specific statement to the contrary is included in this message.

While this communication may be used to promote or market a transaction
or an idea that is discussed in the publication, it is intended to provide
general information about the subject matter covered and is provided with
the understanding that The Principal is not rendering legal, accounting,
or tax advice. It is not a marketed opinion and may not be used to avoid
penalties under the Internal Revenue Code. You should consult with
appropriate counsel or other advisors on all matters pertaining to legal,
tax, or accounting obligations and requirements.

[Gunnar Hjalmarsson]

Hellman, Matthew wrote:
> The answer to your problem seems to be making sure one and only one
> content-type header is returned with the image, and that it has the
> correct value (e.g. Content-Type: image/jpeg or whatever).

Right, and it just struck me that this is probably a web server
configuration issue. A sensibly configured server should send the
correct content-type header out from the file extension.

Please see the attached file, which is the config file for this purpose
on my own (Apache) server. There you can see that a jpg extension
results in content-type image/jpeg, a png extension gives image/png etc.

[Matthew Hellman]

I don't think that's it's a web server thing, because he's dynamically generating the images and not using a .jpg extension. Doing it this way allows you do such things as resize the image on the fly using URL parameters. Something like:

src="/images/showImage.html?imageid=123456&size=800x600

the HTTP response headers would probably shed the most light on the problem, nudge, nudge;-)

[Dermot Paikkos]

> -----Original Message-----
>
> What are you using in showImage.html to print the image? If you're
> doing it manually, then put "print 'Content-Type: image/jpeg\n" at the
> top of the file (w/ a double "\n" at end of header). If using CGI.pm,
> then it's as simple as "print header(-type=>'image/jpeg')" or
> equivalent. If it's an Apache::* module, then there's a similar
> interface, and so on. More than likely what really matters is what
> showImage.html is doing (and/or not).
> --
> Shaun Fryer
> http://sourcery.ca/

Thanx for all the replies.

I must say this list is quite slow compared to others.

Matthew is correct. I used the FF live-headers add-on and the section
for the /images/showImage.html was Content-Type text/html.

As for how the page is generated and images displayed, it's a bit
involved. The whole application is a mod_perl wrapper and templating
system. The showImage.html page is one line that reads as follows:

<%- httpContentType('image/jpeg')%><%= ModName::outputImage(
cgiParam('imageid'))%>

I have tried to go throught the code and find out what sub-class the
httpContentType is but my efforts to hack the code and force the correct
content_type have failed. cgiParma is a sub-class of CGI.

I'm in a pickle because the consequences of this bug are far-reaching.
I'm not in a position to throw out the whole mod_perl application and I
can't think of a way to serve the content that is not htmh from another
handler.

Below is an extract from the mod_perl handler that should be setting the
content type, I have commented out my hack as it didn't work ;-(

Thanx,
Dp.

sub handler
{
# THIS IS THE IMPORTANT FUNCTION
my($apache)=@_;
my $asperl;
if($apache->dir_config('ProjectName') &&
defined($OBJECT{$apache->dir_config('ProjectName')}) &&
ref($OBJECT{$apache->dir_config('ProjectName')}))
{
$asperl=$OBJECT{$apache->dir_config('ProjectName')};
}
else
{
$asperl=$OBJECT{"DEFAULT"};
}
if($apache->dir_config("ServerPort"))
{
$ENV{"SERVER_PORT"}=80;
}
my $data;
# initialise the ASPerl object for this request
my $fname=$apache->filename();
$asperl->{"Request"}=$apache;
# finish initialising the ASPerl object
if(handleThisRequest($asperl,$fname))
{
# we've decided that we want to handle this, so run it through
the ASPerl engine.
$asperl->{"ReturnCode"}=OK;
$asperl->{"CGI"}=new CGI;
# my %media_hacks = (
# 'showImage.html' => 'image/jpeg',
# );
# if (exists $media_hacks{basename($fname)}) {
# print STDERR "Forcing content_type to
$media_hacks{basename($fname)}\n";
# $asperl->setContentType($media_hacks{basename($fname)});
# $asperl->{'Request'}->content_type(
$media_hacks{basename($fname)} );
# $asperl->{'Request'}->header_out( "Content-Type"
=>$media_hacks{basename($fname)} );
# }
# else {
# print STDERR "The current type for request to $fname is
".$apache->content_type()." The ASPerl is
".$asperl->{'ContentType'}."\n";
# print STDERR "ContentType for $fname is now
".$asperl->{'Request'}->content_type."\n";
# }
$asperl->setContentType($apache->content_type());

[Matthew Hellman]

Ah, mod-perl....{{{ shudder }}}.

"$asperl->setContentType($apache->content_type());"

I think there's a bunch of relevant code we're not seeing. Without having been set prior, I don't believe $apache->content_type will return the right header in this situation because it relies on file extension and will typically fail to "text/html". Just for debugging purposes, have you tried simply changing the code to:

$asperl->setContentType($apache->content_type('image/jpeg'));

>>--
>>To unsubscribe, e-mail: beginners-cg...@perl.org
>>For additional commands, e-mail: beginners...@perl.org
>>http://learn.perl.org/