Skip to content
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

Closed
katrinleinweber opened this issue Nov 29, 2014 · 5 comments

Comments

@katrinleinweber
Copy link

moved from #18 (comment)

[...] no_content_length error messages (for each episode that has a /podlove/file/tracking URL) [...]

[...] server is not supplying the Content-Length: header. Are you generating download files on the fly? :)

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?

@timpritlove
Copy link

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.

@astro
Copy link
Owner

astro commented Nov 29, 2014

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

@katrinleinweber
Copy link
Author

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?

@astro
Copy link
Owner

astro commented Jan 20, 2015

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

@astro astro closed this as completed Jan 20, 2015
@katrinleinweber
Copy link
Author

Wrong redirect; fixed now. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants