466965 - reopening a dynamic PHP image included in html page displays garbage

Status: RESOLVED INVALID

(Firefox :: General, defect)

Description

[ffux]

User-Agent:       Opera/9.62 (X11; Linux i686; U; en) Presto/2.1.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.3) Gecko/2008102102 Gentoo Firefox/3.0.3

A link such as follows will load the dynamic image correctly but when clicking the link it opens new tab with text garbage. The raw image data as text.

<a target=_blank href="http://tld.com/image_generator.php&l=100&w=60"><img src="http://tld.com/image_generator.php&l=100&w=60">click image to view in new tab</a>

Reproducible: Always

Steps to Reproduce:
1. include dynamically created image in html page with correct image headers
2. include this image as a link to itself, complete with php and args.
3. visit url , note image is OK
4. click on image link to open new tab with image 
Actual Results:  
As per bug 330920 the resulting "image" is raw data displayed as text.

firefox is not recalling the php on the server (which may be legit) but is failing to correctly open the image it already has as an image. 
‰PNG  ��� IHDR�� ���è���å ���PLTEÿÿÿ��

It seems to have lost track of the fact the data represents an image.


Expected Results:  
display the image data as an image not as text garbage.

Bug 466963 . I am pretty sure that this is a second effect that is a manifestation of the same underlying bug in the code. Somewhere it is failing to recognise that the data is image-png .

Comment 1

[Matthias Versen [:Matti]]

funny bug in your site, 2 content-type headers and Gecko is using the text/html one and renders the data as text/html:

HTTP Status Code: HTTP/1.1 200 OK
Date:	Thu, 27 Nov 2008 17:23:58 GMT	
Server:	Apache/2.2.X (OVH)	
X-Powered-By:	PHP/4.4.9	
content-type :	image/png	
Vary:	Accept-Encoding	
Content-Encoding:	gzip	
Content-Length:	3394	
Connection:	close	
Content-Type:	text/html

Use http://web-sniffer.net and enter the direct image URL to see the headers.

-> invalid

Comment 3

[ffux]

Indeed. Subtle error in php call to header() , space after 'content-type'

PHP seems to add a default text/html if it detects one was not sent. This is unfortunate since the protocol allows the client to detect content type from intial bytes _only in the absence_ of the header info. 

This would have allowed FF to interpret ‰PNG and correctly deal with the data, however the presence of the text header forbids this.

Many thanks for the sniffer link , most helpful. Sorry for incorrectly attributing this to firefox.

best regards.

Comment 4

[Matthias Versen [:Matti]]

I think (but didn't look in the RFCs) that a http/1.1 response without content-type is invalid. Using a http/0.9 response is without content-type header and would trigger a content sniffing in Gecko.

content-type :    image/png    

I don't know where you added this header but you should try to modify it to "Content-Type" instead of "content-type".

Comment 5

[ffux]

thanks Matthias,

sorry if I was not clear. I have solved what was principally my error thanks to the pointers you gave and then checking http spec. 

The header names are not case sensitive but there must be nothing between the header name and the colon. My typo was having a space there, easy to overlook.

This led php to insert its default header which was inappropriate. Gecko was perfectly correct in using the only correctly formed header in the response.

The php action is unhelpful in that it masks the real problem of the badly formed header and also prevents the client from correctly interpretting the data which it otherwise could do.

I am looking into that issue but the bottom line was that correcting the typo in my php code produces one, correctly formed header and all works as it should.

many thanks.