Serendipity Forums

[Lux]

Hi,

MimeTypes for attached media files are evaluated wrongly as text/html

What can we do to get that fixed?

http://www.radiotux.de/index.php?/archi ... -2012.html

Cheers

Dirk

[yellowled]

MimeTypes for attached media files are evaluated wrongly as text/html

What can we do to get that fixed?

I think the plugin needs to emit proper type attributes – audio/mpeg for mp3, audio/ogg for Ogg. Same for video, BTW, although the current status on HTML5 video is a bit iffy because of the changing codec support in browsers. Should be video/ogg, video/mp4 and I think video/webm, I guess.

You could also try adding the proper mime types to your .htaccess, but I'm not sure that would work here since the plugin seems to explicitly emit type="text/html".

YL

[garvinhicking]

Hi!

Phew. That's not easy; since you use absolute URLs, the plugin tries to fetch them via HTTP and use the "content-type" HTTP header attribute; somehow this seems to have returned "text/plain" in that case.

Another variant is that GetID3 is employed and might not properly return the proper mime type; this in turn can depend on your OS on the server and its' mime magic headers.

One more problem is that you have multiple "." in your filename, which can lead to mime-magic detection failures, if the "right" extension might not be properly found.

So there are at least 4-5 variables coming into play here. Hard to say. I could try to debug this, but would need access to such a server, and quite possible break the site for a few minutes to add debugging output. Maybe you have a dev-setup of the whole domain where such breakage could be performed, but which is a complete duplicate of the site?

Regards,
Garvin

[Lux]

Phew. That's not easy; since you use absolute URLs, the plugin tries to fetch them via HTTP and use the "content-type" HTTP header attribute; somehow this seems to have returned "text/plain" in that case.

Yes, maybe.

Another variant is that GetID3 is employed and might not properly return the proper mime type; this in turn can depend on your OS on the server and its' mime magic headers.

Server OS is Debian stable.

One more problem is that you have multiple "." in your filename, which can lead to mime-magic detection failures, if the "right" extension might not be properly found.

There is no problem with multiple dots ... this is an usual Unix filename. I think you use regexps, since they are greedy, there is no issue with that, even if the expression is not well formed.

So there are at least 4-5 variables coming into play here. Hard to say. I could try to debug this, but would need access to such a server, and quite possible break the site for a few minutes to add debugging output. Maybe you have a dev-setup of the whole domain where such breakage could be performed, but which is a complete duplicate of the site?

What kind of access do you need? Shell access? Access to the files?

Does the Easy Podcasting plugin react on mimetypes or on file extensions? If it uses file extensions, it could evaluate mimetypes from the extensions.

What about enhancing Easy Podcasting to react that way? Or give the opportunity to set the mime types manually?

Cheers

Dirk

[Lux]

Update:

Code: Select all

$ wget http://archiv.radiotux.de/sendungen/radiotux/2012-03-31.RadioTux.Magazin.Maerz2012.mp3
[...]
Proxy request sent, awaiting response... 200 OK
Length: 108744092 (104M) [audio/mpeg]

$ wget http://archiv.radiotux.de/sendungen/radiotux/2012-03-31.RadioTux.Magazin.Maerz2012.ogg
[...]
Proxy request sent, awaiting response... 200 OK
Length: 84223212 (80M) [audio/ogg]

$ wget http://archiv.radiotux.de/sendungen/radiotux/2012-03-31.RadioTux.Magazin.Maerz2012.m4a
[...]
Proxy request sent, awaiting response... 200 OK
Length: 75027131 (72M) [text/plain]

Only the mimetype of the last one is wrong.

Cheers

Dirk

[savar]

Hi,

I added the m4a mimetype to our webserver. And saved the article again. Still no change with the htm5 player

Code: Select all

 wget http://archiv.radiotux.de/sendungen/radiotux/2012-03-31.RadioTux.Magazin.Maerz2012.m4a
--2012-04-03 09:22:44--  http://archiv.radiotux.de/sendungen/radiotux/2012-03-31.RadioTux.Magazin.Maerz2012.m4a
Resolving archiv.radiotux.de... 89.238.66.243
Connecting to archiv.radiotux.de|89.238.66.243|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 75027131 (72M) [audio/aac]
Saving to: “2012-03-31.RadioTux.Magazin.Maerz2012.m4a”


Regards,

Ingo

[garvinhicking]

Hi!

There is no problem with multiple dots ... this is an usual Unix filename. I think you use regexps, since they are greedy, there is no issue with that, even if the expression is not well formed.

Just to rule this out as a potential problem, could you try it with a file that only has one dot?

And can you try it also with a local file (no http://...) to maybe make the remote request responsible?

What kind of access do you need? Shell access? Access to the files?

Preferrably shell access, write privileges to the podcast plugin, and a way to login to the s9y backend to edit the article that contains those links.

Does the Easy Podcasting plugin react on mimetypes or on file extensions? If it uses file extensions, it could evaluate mimetypes from the extensions.

Sadly the code is a bit hard to read. What I figure is that it depends on MIME- and CONTENT-Types, file extensions do not actually seem to be used, only as a fallback.

Regards,
Garvin