Please provide a log excerpt that shows the problem.
By default Privoxy removes Range headers in client requests if
filtering is enabled so the server should not respond with a
partial response. While this behaviour can be changed by disabling
filtering for range requests, in this case the size of the server
response should not be modified by Privoxy.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ranges starting at byte 0 are indeed a special case and always
let through, if the range is limited it's thus conceivable that
a server would respond with a Content-Range header set.
Maybe the currently hard-coded special case should be replaced
with a tag-based solution as well. The exception is only relevant
for large multimedia files which Privoxy's default configuration
is not expected to filter anyway.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's a bit messy. For example, VLC always sends Range (for playlists too, which are short text files and feasible for filtering).
Generally, if Range is passed through and filtering occures then Content-Range should be fixed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The upcomming 3.0.25 beta release disables filtering for range request in the default configuration. This was mainly done to get Windows updates working less unreliably but should help here as well.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please provide a log excerpt that shows the problem.
By default Privoxy removes Range headers in client requests if
filtering is enabled so the server should not respond with a
partial response. While this behaviour can be changed by disabling
filtering for range requests, in this case the size of the server
response should not be modified by Privoxy.
Here Range is not removed:
2015-09-02 14:00:32.514 770dc530 Actions: +change-x-forwarded-for{block} +client-header-tagger{css-requests} +client-header-tagger{image-requests} +filter{test} +hide-from-header{block} +set-image-blocker{pattern}
2015-09-02 14:00:32.514 770dc530 Request: 192.168.0.10/
2015-09-02 14:00:32.517 770dc530 Writing: to socket 6: GET / HTTP/1.1\x0d\x0aUser-Agent: curl/7.32.0\x0d\x0aHost: 192.168.0.10\x0d\x0aAccept: /\x0d\x0aRange: bytes=0-\x0d\x0a\x0d\x0a
2015-09-02 14:00:32.519 770dc530 Re-Filter: filtering 192.168.0.10/ (size 2171) with 'test' produced 0 hits (new size 2171).
2015-09-02 14:00:32.519 770dc530 Writing: to socket 3: HTTP/1.1 200 OK\x0d\x0aContent-Type: text/html; charset=UTF-8\x0d\x0aContent-Length: 2171\x0d\x0aDate: Wed, 02 Sep 2015 11:00:32 GMT\x0d\x0aServer: lighttpd/1.4.35\x0d\x0aProxy-Connection: keep-alive\x0d\x0a\x0d\x0a
BTW, how can I disable this default behavior (removing Range)?
Thanks for the log excerpt.
Ranges starting at byte 0 are indeed a special case and always
let through, if the range is limited it's thus conceivable that
a server would respond with a Content-Range header set.
You can disable filtering for range requests using tags:
http://www.privoxy.org/user-manual/actions-file.html#CLIENT-HEADER-TAGGER
Maybe the currently hard-coded special case should be replaced
with a tag-based solution as well. The exception is only relevant
for large multimedia files which Privoxy's default configuration
is not expected to filter anyway.
It's a bit messy. For example, VLC always sends Range (for playlists too, which are short text files and feasible for filtering).
Generally, if Range is passed through and filtering occures then Content-Range should be fixed.
The upcomming 3.0.25 beta release disables filtering for range request in the default configuration. This was mainly done to get Windows updates working less unreliably but should help here as well.