-
-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
solve "no_content_length"-errors, by falling back to "length"-parameter in enclosure? #19
Comments
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 |
According to two header checking tools, my webhoster does serve the For the Podlove Tracking URL of the same file however, the 301 redirect is accompanied by 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 ;-) |
Everything has been looking fine to me, except for the link to kns006. |
Wrong redirect; fixed now. Thank you! |
moved from #18 (comment)
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?The text was updated successfully, but these errors were encountered: