Thread Info
  • State Not Answered
  • Replies 7 replies
  • Subscribers 0 subscribers
  • Views 3395 views
  • Users 0 members are here
Options
Suggested

[6.808] HTTP Proxy Range Requests Ignored

drees
Old bug which has existed since 6.100, but used to work in Astaro V5. Still doesn't work in V7 beta.

For details see my old thread:

https://community.sophos.com/products/unified-threat-management/astaroorg/f/55/t/42968

Here's how to test:

Try a range request (make sure transparent proxy is off):

# telnet www.astaro.org 80
GET /clientscript/vbulletin_editor.css HTTP/1.0
Host: www.astaro.org
Range: bytes=1-25


You should get a HTTP 206 response back which means partial content and only see bytes 1 to 25 of the content.

Now go through the proxy (or turn on the transparent proxy):

# telnet  8080
GET /clientscript/vbulletin_editor.css HTTP/1.0
Host: www.astaro.org
Range: bytes=1-25


You'll see that the entire content is returned, wasting bandwidth.
Parents
  • 0
    As it is impossible to scan partial content, this feature of the HTTP/1.1 protocol is disabled (ignored). As for the bandwith issues, I am not sure how much real impact it causes. In a standard use scenario, the user always downloads the entire content (either by sending multiple range requests or one ordinary get) so the overall throughput would remain the same (even smaller as the headers are only sent once) plus, it may well be that the bandwidth is actually saved on the external interface (internet) as the proxy is caching the content.
  • 0 in reply to Vukasin
    Well, in both versions I have content scanning disabled, shouldn't you be able to enable that feature when that is the case?

    To enable content scanning while enabling range requests, couldn't the proxy download the whole content, scan it, then return the range portion?

    I can see how disabling range requests might help the content filter out when scanning, but that's just one method to bypass the content filter.
Reply
  • 0 in reply to Vukasin
    Well, in both versions I have content scanning disabled, shouldn't you be able to enable that feature when that is the case?

    To enable content scanning while enabling range requests, couldn't the proxy download the whole content, scan it, then return the range portion?

    I can see how disabling range requests might help the content filter out when scanning, but that's just one method to bypass the content filter.
Children
  • 0 in reply to drees
    If the proxy would download the entire content, scan it, and then return only a portion of the data would cause tremendous losses in both performance and bandwidth. Imagine someone downloading a 100M file by asking for 100K ranges. This means that the proxy would effectively pass and scan 100G of data.
  • 0 in reply to Vukasin
    And how is that any worse than the current situation when the client asks for ranges but gets the whole thing back anyway?
  • 0 in reply to drees
    BTW, here are the relevant parts of RFC 2068 - Hypertext Transfer Protocol -- HTTP/1.1 which support my claim that the proxy/cache should return only the range to the client if possible:

    See section 14.36.2:
       A server MAY ignore the Range header. However, HTTP/1.1 origin
       servers and intermediate caches SHOULD support byte ranges when
       possible, since Range supports efficient recovery from partially
       failed transfers, and supports efficient partial retrieval of large
       entities.

       If a proxy that supports ranges receives a Range request, forwards
       the request to an inbound server, and receives an entire entity in
       reply, it SHOULD only return the requested range to its client. It
       SHOULD store the entire received response in its cache, if that is
       consistent with its cache allocation policies.
  • 0 in reply to drees
    First of all please notice the "SHOULD" instead of a "MUST" in the RFC text you quoted. This alone allows the proxy chooses to ignore the range header. 
    Also, as the proxy does not support ranges it cannot send the range response. 
    We will gladly consider adding range support if it turns out to have a significant impact on the proxy's usability but at this point range support is simply not available.
  • 0 in reply to Vukasin
    First of all please notice the "SHOULD" instead of a "MUST" in the RFC text you quoted.
    Isn't that what I said? I never said must, but isn't following RFC suggestions a good idea?
    Also, as the proxy does not support ranges it cannot send the range response. 
    Squid supports ranges, I see it in the process list...
    We will gladly consider adding range support if it turns out to have a significant impact on the proxy's usability but at this point range support is simply not available.
    I think that my company is one of the few that is looking for this support. [:(]
Cookie Information Banner