Closed katrinleinweber closed 9 years ago
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.
Absence of this header for static files is strange indeed. Do you support Range:
requests at all? It won't work without.
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:
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?
Everything has been looking fine to me, except for the link to kns006.
Wrong redirect; fixed now. Thank you!
moved from https://github.com/astro/bitlove-ui/issues/18#issuecomment-64944193
It's a webhosting service, so I'm not sure I can influence what it sends or generates. However, there is definitely a
length
parameter in each file's<enclosure />
(with Podlove Tracking switched on). Can Bitlove be made to fall back to that one?