470199 - File downloads via php header() fail sometimes

Status: RESOLVED INVALID

(Core :: Networking: HTTP, defect)

Description

[Carsten Sann]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5

This is a Typo3 environment using a custom made extension which sends files (pdf, doc, exe) via PHP's header() and readfile() functions. The script works fine (and I am aware that this is not a PHP bugtracker ;-) ).

In FF 3.0.5 you can provoke an error when you do downloads quite quickly and frequently like click the file, abort the download manager, click the next file, abort again, etc. After four to five downloads the download manager won't show up but a garbled view of the html website and the file content is loaded into the html framework of the website (see file attached). 

This problem does not occur when tested with IE or Safari. So it has something to do with FF. The problem also occurs with FF 3.0.4 on Macintosh.

Reproducible: Always

Steps to Reproduce:
1. Go to the website http://www.hameg.com/articles.0.html?&L=1&tx_hmdownloads_pi1[mode]=download&tx_hmdownloads_pi1[uid]=3079
2. Quickly download four or five files (each time abort the download manager ("cancel") to be quicker)
3. Enjoy the garbled website
Actual Results:  
The download manager does not show up but a garbled version of the html website.

Expected Results:  
Download manager should open and download the file.

Comment 1

[Carsten Sann]

Attachment: View of the garbled website after provoking the error

Comment 2

[Matthias Versen [:Matti]]

Please provide a http log : 
http://www.mozilla.org/projects/netlib/http/http-debugging.html

Do you have some Firewall products like Bitdefender installed ?

Comment 3

[Carsten Sann]

Attachment: HTTP log as requested

The last download attempt lead to the erroneous behaviour

Comment 4

[Carsten Sann]

There is no personal firewall installed (except WXP firewall which is disabled). There is a linux based firewall to protect the LAN - the client PC has direct internet access via NAT.

Comment 5

[Carsten Sann]

Any news on this topic?

Comment 6

[Matthias Versen [:Matti]]

A network developer must look into this issue.
This should be the part where it fails :

6[32d640]: nsSocketTransport::SendStatus [this=2fc4a60 status=804b0006]
3776[32d640]: nsHttpTransaction::OnSocketStatus [this=d78740 status=804b0006 progress=315980]
3776[32d640]: nsHttpTransaction::ProcessData [this=d78740 count=4096]
3776[32d640]: nsHttpTransaction::ParseHead [count=4096]
3776[32d640]: nsHttpResponseHead::ParseVersion [version=]
3776[32d640]: looks like a HTTP/0.9 response
3776[32d640]: Have status line [version=9 status=200 statusText=OK]
3776[32d640]: nsHttpTransaction::HandleContent [this=d78740 count=4096]
3776[32d640]: nsHttpTransaction::HandleContentStart [this=d78740]
3776[32d640]: http response [
3776[32d640]: ]
3776[32d640]: nsHttpConnection::OnHeadersAvailable [this=396dc40 trans=d78740 response-head=5dc6b00]
3776[32d640]: waiting for the server to close the connection.

could be still a server issue

Comment 7

[Michal Novotny [:michal]]

This is a server issue. Server appends some HTML to the returned PDF. The Content-Length header contains size of the PDF only and so the HTML code isn't read and is recognized as a HTTP/0.9 response to the next request.

see output of :

echo -e "GET /articles.0.html?&L=1&tx_hmdownloads_pi1[mode]=download&tx_hmdownloads_pi1[uid]=3079 HTTP/1.1\r 
Host: www.hameg.com\r 
\r\n" | nc www.hameg.com 80 > reponse.txt


Patch #343299 in bug #363109 (which is similar to this bug) fixes this issue too.

Comment 8

[Matthias Versen [:Matti]]

Thanks Michal for investigating this and I hope biesi will finally review your patch !

Comment 9

[Carsten Sann]

Thanks from me, too for the perfect investigation. I found a way to prevent Typo3 from sending the additional HTML. Thank you again!