Friday, July 28, 2006
Feedburner doesn't support Enclosure Redirect?
Feedburner doesn't support Enclosure Redirect?
I'm helping a client with their audio podcast feed and it appears that through feedburner, the enclosure URLs are rewritten to go "through" feedburner. I assume this is to more accurately track traffic. It's not clear to me whether these rewritten URLs are redirected or byte-by-byte passthrough.
The problem is that these rewritten enclosure URLs do not appear to support the HTTP RANGE request, which prevents what is commonly known as "resume". I can't immediately tell who is at "fault", but it is very common that a flat file on an HTTP server (such as that which would be pointed to by a "redirect") does support the HTTP RANGE request.
If Feedburner is using byte-by-byte passthrough, then you should add support for the RANGE request. If Feedburner is using a redirect, then it could be a problem with one of the following.
1) HTTP: Does HTTP Redirect support a RANGE request in the redirection?
2) Feedburner: Does Feedburner support the redirected RANGE request?
3) .NET Compact Framework: Does the library I'm using in my application support the redirected RANGE request?
4) HTTP Server: Does the clients' server support the RANGE request? (it is extremely likely that the RANGE request is supported here)
Can Feedburner confirm that at least that 1 and 2 are true?
For mobile devices, this causes a HUGE problem when the connection length is less than the download length (which is often the case with GPRS downloading 36 MB).
I'm helping a client with their audio podcast feed and it appears that through feedburner, the enclosure URLs are rewritten to go "through" feedburner. I assume this is to more accurately track traffic. It's not clear to me whether these rewritten URLs are redirected or byte-by-byte passthrough.
The problem is that these rewritten enclosure URLs do not appear to support the HTTP RANGE request, which prevents what is commonly known as "resume". I can't immediately tell who is at "fault", but it is very common that a flat file on an HTTP server (such as that which would be pointed to by a "redirect") does support the HTTP RANGE request.
If Feedburner is using byte-by-byte passthrough, then you should add support for the RANGE request. If Feedburner is using a redirect, then it could be a problem with one of the following.
1) HTTP: Does HTTP Redirect support a RANGE request in the redirection?
2) Feedburner: Does Feedburner support the redirected RANGE request?
3) .NET Compact Framework: Does the library I'm using in my application support the redirected RANGE request?
4) HTTP Server: Does the clients' server support the RANGE request? (it is extremely likely that the RANGE request is supported here)
Can Feedburner confirm that at least that 1 and 2 are true?
For mobile devices, this causes a HUGE problem when the connection length is less than the download length (which is often the case with GPRS downloading 36 MB).