521005 - MIME type file extension confusion

Status: RESOLVED INVALID

(Firefox :: File Handling, defect)

Description

[Charlie Jin]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3

In the above site, a music in embeded and FireFox reports the following error:

The movie “pcp_download.php” can’t be opened.

However, as you see in below, "php_download.php" is just a web application that downloads the actual music, and the complete url should be "http://cfs11.planet.daum.net/upload_control/pcp_download.php?fhandle=NXJWcGxAZnMxMS5wbGFuZXQuZGF1bS5uZXQ6LzE2MDkyMjQ2LzAvNTkud21h&filename=59.wma" and the extension is wma.

<<embed src="http://cfs11.planet.daum.net/upload_control/pcp_download.php?fhandle=NXJWcGxAZnMxMS5wbGFuZXQuZGF1bS5uZXQ6LzE2MDkyMjQ2LzAvNTkud21h&amp;filename=59.wma" type="video/x-ms-wmv" width="250" height="40" volume="0">

Note also, that IE, Safari and other browsers don't exhibit this problem.
Only FireFox has have this problem for many years and have not been fixed yet.
A lot of Korean portals use this method to link the music, but since FireFox cannot recognize  this kind of type url and thus cannot play the music, FireFox becomes the least favorite browser in S. Korea, which also causes Linux to be unpopular. I think that this should be fixed as soon as possible, so that general public in S. Korea may also recognize FireFox as "functioning" browser. At this moment, FireFox is not considered as a "functioning" browser in there, for various reasons, and this is one of the chief reasons. Thanks.

Reproducible: Always

Steps to Reproduce:
1. Go to the indicated web page.
2. The music should be played ( it's wma file )
3. FireFox indicates that it needs plugin to be installed.
Actual Results:  

In case of Mac (with Flip4Mac installed), it says: 
"The movie “pcp_download.php” can’t be opened."

Expected Results:  
The wma file should be played as in other browsers (ex IE, Safari )

http://cfs11.planet.daum.net/upload_control/pcp_download.php?fhandle=NXJWcGxAZnMxMS5wbGFuZXQuZGF1bS5uZXQ6LzE2MDkyMjQ2LzAvNTkud21h&amp;filename=59.wma

Comment 1

[Ralf Vitasek]

As you noticed yourself this is because of a missing plugin.
It's just not possible that Firefox could directly integrate a plugin to play the proprietary Microsoft format especially with various possible ways of protecting the content with DRM.

When on windows it's should probably work with the Media Player plugin. On any other platform it's just not feasible.

Annoying and disappointing, but in the end it's not a bug.

Comment 2

[Charlie Jin]

No, this is NOT because of a missing plugin.
Plugin is there for wma. This is NOT related with DRM.
The problem with FireFox is that it erroneously recogizes the following url to have the extension of *.php.

http://cfs11.planet.daum.net/upload_control/pcp_download.php?fhandle=NXJWcGxAZnMxMS5wbGFuZXQuZGF1bS5uZXQ6LzE2MDkyMjQ2LzAvNTkud21h&filename=59.wma

 So, FireFox is asking for a plugin for "php" in an attempt to play "upload_contrtol.php", which is not correct. There is some parsing problem in Firefox.  Also, note that Safari in Mac can play without any problem, even though Mac is not originally able to play WMA file. However, many Mac users, including me, install wma plugin for FireFox and Safari (called Flip4Mac).

As a matter of fact, FireFox can play WMA or ASF files. For example,
see http://cafe.daum.net/seattleguitar/IImP/55  

In there,
<embed style="width: 300px; height: 45px;" src="http://y5line2.com.ne.kr/inst/IlSilenzio.asf" autostart="false" allowscriptaccess="never" invokeurls="false" volume="0" loop="-1" allownetworking="internal">

Note the src url: http://y5line2.com.ne.kr/inst/IlSilenzio.asf 

and the problem url: http://cfs11.planet.daum.net/upload_control/pcp_download.php?fhandle=NXJWcGxAZnMxMS5wbGFuZXQuZGF1bS5uZXQ6LzE2MDkyMjQ2LzAvNTkud21h&amp;filename=59.wma

The problem url has ".php" extension in the middle and also "?".
I suspect that this may confuse FireFox and thus it parses the url string unsuccessfully.

Thanks.

Comment 3

[Ralf Vitasek]

ok, but i still don't see a bug in firefox.
not even a missing feature yet.

requesting the mentioned "problem url":

Date	Wed, 07 Oct 2009 16:56:20 GMT
Server	Apache
X-Powered-By	PHP/4.4.4
Content-Type	text/html
Via	1.1 cfs11-2 (Jaguar/3.0-72)
Connection	close

You complain about the URL not being parsed successfully, this is not true.
The requested file is a .php file with some requester that adds a file name. that itself is perfectly fine and is not causing problems at all.

What is NOT fine is the fact that the server says it's of content type text/html.
Even when trying to play it directly in Quicktime, VLC or Mplayer any program refuses to open that URL.

I'm not sure what mime it is supposed to be, the content looks like some sort of playlist, definetly not html.

If you have the plugins to play the file then it most likely would play when served with the correct mime-type.

Comment 4

[Charlie Jin]

Why do you think that it is not a bug, when this is clearly a bug ?

The reason is that it is not just a file, it is streaming.
And FireFox considers the media files URL as "*.php" which is not correct.
Try open it using Safari (with Windows Media File plugin).

For example in http://cafe.daum.net/seattleguitar/IImP/61

Safari in Mac, and IE in Windows play fine.

The tag for embedding is as follows:

<embed src="http://cfs10.planet.daum.net/upload_control/pcp_download.php?fhandle=NXJWcGxAZnMxMC5wbGFuZXQuZGF1bS5uZXQ6LzE2MDkyMjQ2LzIvMjcwLndtYQ==&amp;filename=270.wma" omcontextmenu="return false" loop="-1" volume="0" height="40" width="250">

In fact, in the browsers, it doesn't need the mime type specified in the embed tag. However, type="video/x-ms-wmv" also works.

The reason why VLC doesn't work is different from FireFox. It also parses wrong and it considers the string after "?"  (fhandle=NXJWcGxAZnMxMC5wbGFuZXQuZGF1bS5uZXQ6LzE2MDkyMjQ2LzIvMjcwLndtYQ==&amp;filename=270.wma) as a file name, which is again wrong.

So, Firefox and VLC both parses wrong in completely different way.
(FireFox considers "http://cfs10.planet.daum.net/upload_control/pcp_download.php" as a file name to be played, which is wrong again.

Comment 5

[Matthias Versen [:Matti]]

An extension doesn't matter at all for http content !
It does in IE but that is a bug in IE and violates the HTTP RFC.
If Safari does the same you should create a bug report at apple that they violate the http RFC.
Forget your talking about .ogg/.php extensions, they doesn't matter !

The content-type/mime-type send by the server is that what matters.
Please post the headers for the file from the server and if ou have a plugin in about:plugins (enter as URL in Firefox) that supports this content-type.

Comment 6

[Ralf Vitasek]

Response Headers - http://cfs11.planet.daum.net/upload_control/pcp_download.php?fhandle=NXJWcGxAZnMxMS5wbGFuZXQuZGF1bS5uZXQ6LzE2MDkyMjQ2LzAvNTkud21h&filename=59.wma

Date: Wed, 07 Oct 2009 18:52:16 GMT
Server: Apache
X-Powered-By: PHP/4.4.4
Content-Type: text/html
Via: 1.1 cfs11-2 (Jaguar/3.0-72)
Connection: close

200 OK

##

like i said in comment #3, the server delivers text/html content.
so it's a server error that happens to be ignored by IE and Safari.

the reporter should send a mail to the webmaster of that site and ask for a fix.

Comment 7

[Charlie Jin]

No, the server is doing its job fine.
It is the FireFox's problem.
It doesn't matter wheather it returns txt file or html.
Even then, FireFox should not cut the url string and try to find a plugin for
*.php file. This is completely wrong.

Also, as you see in the url, it is "upload_control", which indicates that it can be any file. So, the server does not need to give the every detail of MIME type it has. In fact, the server does not need to care, since it simply functions as some repository for any files.

So, as far as <embed > tag is concerned, why FireFox has to chop the URL off in the middle ? This just doesn't make any sense. You just need to give the whole URL string to the plugin cotroller. The plugin controller will either use the plugin handler for the MIME type specified inside <embed> tag, or use the last extension string after the LAST dot, and select the default plugin handler for the extension. 

What is possible is that FireFox's plugin controller selects the extension string after the FIRST dot, which causes to try to select the plugin for *php.
If it gets the extension string after the LAST dot, like other browsers, it should work fine.

Comment 8

[Matthias Versen [:Matti]]

The URL posted in the bug itself contains only "321" as content and is served as text/html (comment #6)
I thought the WMP file could be blocked for my location but Ralf got the same content for the URl.

The headers extracted from the URL in the bug header is send with this headers :

  HTTP/1.1 200 OK
  Date: Wed, 07 Oct 2009 19:15:30 GMT
  Server: Apache
  X-Powered-By: PHP/4.4.4
  Last-Modified: Sun, 05 Nov 2006 02:51:20 GMT
  Cache-Control: must-revalidate,max-age=86400
  Accept-Ranges: bytes
  Content-Disposition: attachment;filename="59.wma"
  Content-Length: 979569
  Content-Type: application/octet-stream
  Via: 1.1 cfs11-1 (Jaguar/3.0-72)
  Age: 7
  Expires: Thu, 08 Oct 2009 10:15:24 GMT
  Connection: Keep-Alive
Length: 979569 (957K) [application/octet-stream]

The content-type is wrong content-type, marking this bug report invalid
If you have questions about this read in the HTTP 1.1 RFC about the content-type header

Comment 9

[Matthias Versen [:Matti]]

Got a mid-air with the last comment from the reporter.

>Also, as you see in the url, it is "upload_control", which indicates that it
>can be any file. So, the server does not need to give the every detail of MIME
>type it has. In fact, the server does not need to care, since it simply
>functions as some repository for any files.

That violates the HTTP 1.1 RFC. Your server must send the right content-type for all documents that is serves.

>So, as far as <embed > tag is concerned, why FireFox has to chop the URL off in
>the middle ? This just doesn't make any sense. You just need to give the whole
>URL string to the plugin cotroller. The plugin controller will either use the
>plugin handler for the MIME type specified inside <embed> tag, or use the last
>extension string after the LAST dot, and select the default plugin handler for
>the extension. 

A mime-type given by the server overrides any other types, 
The extension is never used because the file extension doesn't matter.

>What is possible is that FireFox's plugin controller selects the extension
>string after the FIRST dot, which causes to try to select the plugin for *php
>If it gets the extension string after the LAST dot, like other browsers, it
>should work fine.

Again, extensions doesn't matter

Comment 10

[Charlie Jin]

OK, guys, I give up.
We will simply not use Firefox.
Besides, other browsers work just fine, they have more functionalities.
In fact, I was really amazed by Safari in Snow Leopard (development module).
There is no reason why I am trying to promote FireFox.
Thank you. Bye.

Comment 11

[Matthias Versen [:Matti]]

>A mime-type given by the server overrides any other types,

That might be wrong, it's possible that a given content-type in an object/embed tag overrides the wrong server type. The original URl is working for me on the trunk with the WMP plugin installed.