dean gaudet wrote:
how does that work when the browser is making a byterange request on a
massive object... does the proxy strip the byterange before sending to the
upstream?
if so... ew.
it would seem the proxy needs to do byteranges (including caching of
partial content)... or treat
how does that work when the browser is making a byterange request on a
massive object... does the proxy strip the byterange before sending to the
upstream?
if so... ew.
it would seem the proxy needs to do byteranges (including caching of
partial content)... or treat byterange requests as
Hi all,
The byterange filter currently assumes that none of the content
generators or filters upstream is capable of handling range requests
themselves. As a result the filter will try to do a byterange on a
byterange.
The attached patch tells the byterange filter to back off if there
already
Graham Leggett wrote:
+if ((ct = apr_table_get(r-headers_in, "Content-Type"))
+(!strncasecmp(ct, "multipart/byteranges", 20) ||
+ !strncasecmp(ct, "multipart/x-byteranges", 22))) {
+ return 0;
Oo-er! This is only half the story - single byte ranges must also be
[EMAIL PROTECTED] wrote:
Quick question, is the proxy handling byte-range, or is the up-stream
server handling it? If the proxy module is handling it, then I believe
that the answer is to stop having the proxy handle it. If the up-stream
server is doing the work, then +1 for this patch.
