Squid's handling of HTTP range and Range_offset_limit

Range_offset_limit

A Range Request comes from a client this wants only some subset of an HTTP response. They is sometimes used to resume a failed transfer of a large file. Squid isn ' t yet able to cache partial responses and thus must make a decision when forwarding a range Request:either Remo ve the Range header or leave it in.

If Squid leaves the Range header in, the origin server sends only the subset, the client wants, and the Clien T receives the response immediately. However, this partial response isn ' t cached.

On the other hand, if Squid removes the header before forwarding, it receives the entire response, which could be cached. Squid is then responsible for ensuring, the client receives only the subset it needs. The origin server may send a lot of data the client doesn ' t want. Depending on the speed of your connection, the client could be forced to wait a long time until it range is available.

If the beginning of the requested range is larger than the Range_offset_limit value, Squid forwards the range Header and doesn ' t cache the response. Setting Range_offset_limit to 0 causes Squid to always forward the range header (the default). Setting it to -1 causes Squid to never forward the header.

Syntax	Size-specification
Default	Range_offset_limit 0 KB
Example	Range_offset_limit MB

Question:

> Range Headers-from My understanding, it looks like they
> Video streaming. It looks like the client can request a part of the object
> body to is sent alone to him. Is it correct? In the case, if multiple
> ranges was requested, is it sent separately or in a consolidated manner?

I ' m not sure-your use case is, but I ' ve been playing with YouTube
Caching lately, and range headers play a, trying to cache
Client requests.

Squid won ' t cache range header requests for specific byte ranges.
However, squid can accept range headers from client and discard them
When sending upstream.

Range_offset_limit-1 [<optional_acl>]

Would do the job. I use a ACL to only apply it to specific domains I
Want the behaviour for.

Squid would serve the client the correct bytes, but by discarding the
Range headers for the upstream retrieval, it'll cache the whole
object and subsequent range requests for the cached object would result
In a hit.

Parallel simultaneous requests to the same object with a range header
Would likely result in parallel, full retrieval of the whole file
Though (I say likely as I Havn ' t tested but suspect that'll be the
case).

A related behaviour on the YouTube specifically (and possibly others) is
The use of ' &range=x-y ' URL parameters instead of range header
Requests. I ' ve noticed this and web-browsers on PCs, whereas I ' ve
Seen the range header requests on Apple IOS mobile platforms.

There has been some clever tricks using storeurlrewrite or StoreID to
Include the range bytes in the key of the object stored, so without
The use of range_offset_limit, squid can store an object per unique
Client range request & provide a hit for subsequent requests. My
Testing have indicated this was unreliable as the byte-ranges tend to be
Dynamic based on the clients current bitrates so Off-by-one range
Requests result in a lot of duplication in the cache.

You can also utilise a ICAP server to does even funkier stuff like
Mould range URL parameters to range header requests so the different
Client behaviours share the same cache objects.

The above is excerpted from some of the foreign website's exposition and question and answer.

The first thing to make clear is that squid does not cache partial content, and what we want to do is to handle the back-to-source request in the event that the file is not fully cached.

Combination configuration:

Range_offset_limit #超出此值将forward Range Header, otherwise remove range
Quick_abort_min MB #小于此值将继续从源服务器完成下载
Quick_abort_max MB #超出此值将放弃从源服务器下载
quick_abort_pct #进度超出此值将继续从源服务器完成下载

The above configuration needs to be set up according to business requirements and statistical data.

Squid's handling of HTTP range and Range_offset_limit