633993 - Some links in that webpage are not reconised by Firefox or it tries to download a octet-stream application

Status: RESOLVED INVALID

(Core :: Networking: HTTP, defect)

Description

[videoclocknet]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13

Browsing this webpage and clicking to the "Downloads" link, causes Firefox to try to download an octet-stream file. If I press Cancel and click the same link again, Firefox appears with the typical "Loading" but the webpage is never opened.

Reproducible: Always

Actual Results:  
The link "Download" and some other links in this webpage are not recognised by Firefox or it tries to open an octet-stream or it appears "Loading" but never occurs


I'm using Windows XP, Firefox 3.6.13

Comment 1

[Tim (fmdeveloper)]

WFM - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 ID:20101203075014

Does the issue still occur if you start Firefox in Safe Mode? http://support.mozilla.com/en-US/kb/Safe+Mode

How about with a new, empty profile? http://support.mozilla.com/en-US/kb/Basic+Troubleshooting#Make_a_new_profile

Comment 2

[Bebe]

This SOMETIMES happens to me on:
Mozilla/5.0 (Windows NT 5.1; rv:2.0b12pre) Gecko/20110213 Firefox/4.0b12pre
clean profile

Comment 3

[Henri Sivonen (:hsivonen)]

Why was this assigned to HTML: Parser? Why was this marked [orange]?

Comment 4

[Alex Lakatos[:AlexLakatos]]

I marked it [orange] because it is not always reproducible. And I moved it to HTML:Parser because after i saw the output it shows in Minefield i belive it to be a Parser error.

Comment 5

[Alex Lakatos[:AlexLakatos]]

Attachment: screenshot

Comment 6

[videoclocknet]

Attachment: That's what I see when I click in one link

Comment 7

[Alex Lakatos[:AlexLakatos]]

Try opening it with a Text Editor.

Comment 8

[Robert Longson [:longsonr]]

[orange] means that one of the unit tests in the firefox build process fails.

Comment 9

[videoclocknet]

I've opened Firefox in safe mode creating a new empty profile and it still ocuurs.

Comment 10

[Alex Lakatos[:AlexLakatos]]

Thanks for clearing this up Robert.

Comment 11

[Alex Lakatos[:AlexLakatos]]

Reporter, have you tried to open the octet stream with a Text Editor, like Notepad for example?

Comment 12

[videoclocknet]

If I press download the octet-stream, it appears "beginning the download" and takes forever. See the new attached screenshot

Comment 13

[videoclocknet]

Attachment: Not loading the octet-stream

Comment 14

[Henri Sivonen (:hsivonen)]

Based on the screenshot, it looks *very* unlikely that this was a parser problem. Most likely this is a site problem. However, if it is a Gecko problem, it's most likely a networking problem judging from the screenshots.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Can you please create an HTTP log per instructions at https://developer.mozilla.org/en/HTTP_Logging ?

Comment 16

[Tim (fmdeveloper)]

Attachment: HTTP Debug Log

Was able to reproduce on Mozilla/5.0 (Windows NT 5.1; rv:2.0b12pre) Gecko/20110215 Firefox/4.0b12pre ID:20110215030353 intermittently. The 2nd connection in the attached HTTP Log exhibited the issue.

Comment 17

[videoclocknet]

Attachment: Trying to open "Issues" webpage

The "Loading" message doesn't appear in any link with Internet Explorer 6.

IE 6 recognises that this webpage have errors (see the logo in the down left area)

Comment 18

[videoclocknet]

Attachment: Trying to open isuues webpage

The "Loading" message doesn't appear in any link with Internet Explorer 6.

IE 6 recognises that this webpage have errors (see the logo in the down left area)

Comment 19

[videoclocknet]

Attachment: I've redownloaded the "8IxxfMja.part" from the redownload button from downloads window and that's what it contains

Comment 20

[videoclocknet]

If it was a site problem it would happen in Internet Explorer too, right?

Correct me if I'm wrong.

Comment 21

[Boris Zbarsky [:bzbarsky]]

From the attached log, this looks like the relevant bit for the downloads/ link:

3512[82c780]: nsHttpTransaction::OnSocketStatus [this=6c25110 status=804b0006 progress=26757]
3512[82c780]: nsHttpTransaction::ProcessData [this=6c25110 count=297]
3512[82c780]: nsHttpTransaction::ParseHead [count=297]
3512[82c780]: nsHttpResponseHead::ParseVersion [version=]
3512[82c780]: looks like a HTTP/0.9 response

Patrick, did you recent patches to that stuff fix things here, perhaps?

> If it was a site problem it would happen in Internet Explorer too, right?

Not necessarily.  The most common site problems are bogus browser sniffing or different behavior depending on the features the browser advertizes...

Comment 22

[Patrick McManus [:mcmanus]]

(In reply to comment #21)

> 3512[82c780]: looks like a HTTP/0.9 response
> 
> Patrick, did you recent patches to that stuff fix things here, perhaps?
> 

it's plausible certainly.. but this is WFM on both 4.0 and 3.6..

Comment 23

[videoclocknet]

Hi again!

I've tried to get a HTTP logging activity following the steps of the link you provided me, but I can't get it working (I'm new helping the Mozilla community). I've written a post in mozillazine forum explaining it:
http://forums.mozillazine.org/viewtopic.php?f=38&t=2140259


However I've got some important packets in Wireshark with the filter 'http', using Windows XP, and Firefox 4.0. The wireshark version is in the screenshot I've uploaded

I explain the three files:
documentation_NOTLOAD.pcap: In this scenario I've clicked documentation webpage and firefox shows the typical "Loading webpage" but nothing happens

documentation_OCTETSTREAM.pcap: In this scenario I've clicked documentation webpage and firefox shows the message "Trying to download a octet-stream" that I refered in other comments and you can see in the screenshot

another_documentation_OCTET_STREAM.pcap: In this scenario I've also clicked documentation webpage and firefox also shows the same message "Trying to download a octet-stream" that I refered in other comments and you can see in the screenshot

issues_OK-documentation_OK.pcap: In this scenario I've clicked the issues webpage, which has loaded well. Then I've clicked documentation webpage and it has also loaded well.

Regards.

Comment 24

[videoclocknet]

Attachment: wireshark version

Comment 25

[videoclocknet]

Attachment: documentation_NOTLOAD.pcap

Comment 26

[videoclocknet]

Attachment: documentation_OCTETSTREAM.pcap

Comment 27

[videoclocknet]

Attachment: another_documentation_OCTET_STREAM.pcap

Comment 28

[videoclocknet]

Attachment: issues_OK-documentation_OK.pcap

Comment 29

[videoclocknet]

> However I've got some important packets in Wireshark with the filter 'http',

without the quotes, of course.

Regards.

Comment 30

[Boris Zbarsky [:bzbarsky]]

> but I can't get it working

Hmm...  Try disabling all plug-ins and seeing whether that helps?

Nothing in the wireshark logs is obviously making it clear why we'd think something is application/octet-stream....

Comment 31

[videoclocknet]

Yeah, now it works:
1.- Disabled all plugins abd extensions

2.- I run the two commands in cmd.exe

3.- I run Firefox also from cmd.exe

4.- My home page is opened

5.- I go to http://projects.javatic.net/p/easywemp/ which is shown correctly

6.- I try to go to http://projects.javatic.net/p/easywemp/doc/ , but the window "Trying to open a octect-stream application appears". I click to save

7.- In the downloads window, I can read "Beginning download" in spanish, but the download never begins.

8.- I close firefox and the downloads window. This message appears: "Do you want to cancel the download?" I click yes

9.- I open log.txt and save it.

You can read it in the attachment.

Comment 32

[videoclocknet]

Attachment: The http logging activity happening the bug

Comment 33

[videoclocknet]

(In reply to comment #31)
> Yeah, now it works:
I refer to the http logging activity, of course. The octet-stream application message continues appearing even disabling all plugins and extensions.

Regards

Comment 34

[videoclocknet]

What's the status of this?

Comment 35

[videoclocknet]

Attachment: Bug in Firefox 4.01 in Ubuntu 11.04

Comment 36

[Boris Zbarsky [:bzbarsky]]

> What's the status of this?

Sorry, this was somewhere in the middle of my todo queue...

Looking at the log from comment 32 now, there's no mention of octet-stream.

Do you happen to recall which link (which url) from that log led to the dialog you saw?

Comment 37

[Boris Zbarsky [:bzbarsky]]

Note that the screenshots in comment 35 and comment 5 seem to show a bug on the server side, and in particular malformed HTTP responses...

Comment 38

[videoclocknet]

> Sorry, this was somewhere in the middle of my todo queue...
You're welcome

 
> Looking at the log from comment 32 now, there's no mention of octet-stream.
> 
> Do you happen to recall which link (which url) from that log led to the
> dialog you saw?
I don't know exactly what you refer. You can read in comment 31 what I tried. I tried to open "http://projects.javatic.net/p/easywemp/doc/" and then the "Trying to open a octect-stream application" appeared. But it appears not only in the .../doc/ webpage, but in more pages in this same server, and in a randomly way.

Maybe there's some bug in terms of concurrence in the server side

Comment 39

[Boris Zbarsky [:bzbarsky]]

> You can read in comment 31 what I tried.

Aha, perfect.

So here's what things look like from the browser end there:

1)  We do a GET for http://projects.javatic.net/p/easywemp/doc/
2)  The response is not HTTP/1.0 hence has no headers hence we have to guess at
    the MIME type.
3)  We end up guessing application/octet-stream for some reason.

I'm not quite sure why #3 happens yet, but #2 happens because we see garbage on the persistent HTTP connection when expecting the "HTTP/1." status line.

Patrick, can you take a look at the attached packet captures to see what's up with that?

Comment 40

[Patrick McManus [:mcmanus]]

(In reply to comment #39)

> Patrick, can you take a look at the attached packet captures to see what's
> up with that?

#1 doesn't capture any HTTP

#2 and #3 (failure cases), show a request for easywemp/doc on an already established connection. A legit HTTP/1.1 response is returned in each case. However, I suspect there is already "extra junk" sitting on the connection that has been sent before the capture started.. it just hasn't been consumed by firefox yet, because there is no outstanding request.

#4 is a success case - and it shows a healthy request/response pair preceeding the /doc transaction on the same connection.

So those captures aren't really that helpful.

Comment 41

[Patrick McManus [:mcmanus]]

If you work the log you can see, as Boris notes, easywemp/doc being interpreted as HTTP/0.9.. going backwards from that you can see that the transaction previous to that on the same connection is:

http://projects.javatic.net/p/easywemp/source/tree/master/site/wemp-sample-daemon.png

When I test that out - it is indeed broken as all git out.

If you download it you will see it labeled in the header as image/png and 22441 bytes long.. and indeed what is downloaded is 22441 bytes of png PLUS about 600 bytes of js (something about 'piwik')

The next transaction sees this as the response header to the easywemp/doc request and we head off into undefined territory. extra JS on the tail of a well defined image isn't something we have code for :)

Best bet is that it is being injected by the entity responsible for this header: "X-Powered-By: Pluf - http://pluf.org/ .. and the first step should be evangelism with them and/or the content hoster.

Second, can the reporter try out a recent aurora (FF 6) build and try and reproduce this? That branch has code that tests a persistent connection for pending read data before it is reused - that's a safety check that is actually part of syn retry. It will probably cover you here, though it is technically racy and doesn't work with ssl. (i.e. the JS might not have arrived when we decide to reuse the connection) - so fixing the server seems the right thing to do, that's clearly broken in any event.

Comment 42

[Patrick McManus [:mcmanus]]

comment 37