solve "no_content_length"-errors, by falling back to "length"-parameter in enclosure? about bitlove-ui HOT 5 CLOSED

Bitlove compares both values to check for updated files. Not delivering a Content-Length header for static files is configuration bug in the server infrastructure.

from bitlove-ui.

Absence of this header for static files is strange indeed. Do you support Range: requests at all? It won't work without.

from bitlove-ui.

According to two header checking tools, my webhoster does serve the Content-Length and Accept-Ranges: bytes if the file's URL is used, for example:
http://www.konscience.de/wp-content/uploads/kns025-flucht-nach-vorn-in-die-botanik.m4a
Same result using the ?ptm_ parameters; as expected, I guess.

For the Podlove Tracking URL of the same file however, the 301 redirect is accompanied by Content-Length: 0 by the 1st tool, while the 2nd one reports only HTTP/1.1 200 OK and Content-Type => text/html; charset=UTF-8. Example:
http://www.konscience.de/podlove/file/1693/s/download/c/buttonlist/kns025-flucht-nach-vorn-in-die-botanik.m4a

If I set up a 301 redirect in Podlove's Expert Settings manually from one audio file's direct URL to another, the correct headers are also sent.

I don't know, but it looks to me as if:

• either the automatic PTM redirecting doesn't work as well as the its manually set up redirects
• or my hoster specifically omits the correct headers if a PTM redirect is in place

In any case, I'm sure now it isn't a Bitlove issue, except for the feature request idea of the fall-back ;-)
Shall we move the problem part of this issue to Podloves's tracker?

from bitlove-ui.

Everything has been looking fine to me, except for the link to kns006.

from bitlove-ui.

Wrong redirect; fixed now. Thank you!

from bitlove-ui.