>>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 conn...@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.


--
To unsubscribe, e-mail: beginners-cgi-unsubscr...@perl.org
For additional commands, e-mail: beginners-cgi-h...@perl.org
http://learn.perl.org/


Reply via email to