It's all about the answers!

Ask a question

Disable partial GET request in client/server side?

Makson Lee (41044241) | asked Jul 05 '13, 2:11 a.m.
We have Squid content proxy server installed, but we find that lots of HTTP 206 (Partial Content) response found in Squid store.log, that means,

1. RTC client made a partial GET request.
2. Squid would not cache HTTP 206 response.

So, is it possible to disable partial GET request in client/server side?

Accepted answer

permanent link
Abraham Sweiss (2.4k1331) | answered Jul 11 '13, 7:57 p.m.
Hi I checked with RTC developement, and got the following responses:

From some digging, partial GETs appear to have been implemented to support failed content downloads due to flaky connections.

So as you noted, working around partial GETs would mean that even if the client had downloaded part of a file already and now wanted to resume from a given offset, the server would just ignore the range headers and send back the entire file.

So I guess for starters, the customer should only use the squid workaround if they are okay with what appears to be additional load/traffic.


If your SQUID cache resides on the client side of a flaky network connection, converting the partial GETs to full GETs could potentially defeat the content retry mechanism, or at least make it less effective.
Makson Lee selected this answer as the correct answer

Makson Lee commented Jul 11 '13, 9:47 p.m.

The problem we got is, our remote site users are wondering why does it still take a long time to download the BIG file the second time?

To avoid this situation, we have the Squid to ignore range headers even though doing this may cause the first time download to be finished with more time.

2 other answers

permanent link
Abraham Sweiss (2.4k1331) | answered Jul 09 '13, 2:18 p.m.
edited Jul 09 '13, 8:53 p.m.
Disabling the requests that generate the 206 response in RTC is not possible.  The reason for these request is most likely do to a workitem query.  If squid supports range and content range headers, then it should be able to cache these requests. 

Abraham Sweiss commented Jul 09 '13, 8:12 p.m.

NOTE: These get requests could also be coming from feeds.   And it may not be a good idea to cache these requests.  reason being is that the results of the queries can keep changing quicly, so caching these type of requests may add a slight performance degradation.  However until tested in your environment this is only speculative.

Makson Lee commented Jul 09 '13, 8:59 p.m.

Thanks for the reply, but no, these partial content requests come from IVersionedContentService, and, Squid can't cache the responses to them.

1372991650.893 RELEASE -1 FFFFFFFF 4C7ED6F77157EEE15599812A3CA559F7 206 1372991235 0 1404095235 application/octet-stream 297787296/72302592 GET https://proxy.domain:9443/ccm/service/

permanent link
Abraham Sweiss (2.4k1331) | answered Jul 09 '13, 11:33 p.m.
For services, there is no mehcanisme I am aware of to modify their behavior.

Currently there is an effort to improve the administration of services.  i would suggest openning an enhancement request.

Makson Lee commented Jul 10 '13, 4:26 a.m.

Actually, by setting Squid directive range_offset_limit to none, we can have Squid to remove the partial request header, looks like working fine to us.

Abraham Sweiss commented Jul 10 '13, 6:46 p.m. | edited Jul 10 '13, 7:37 p.m.

Never worked with the range_offset_limit parameter before.  After reviewing looks to be a cool solution.  By setting this, did you see any indication of improved performance.

@jmlennon can you take a look at this.  Any concerns / comments

Makson Lee commented Jul 10 '13, 8:55 p.m.

In our case, yes, the Squid cache hit rate is higher than before now.

Makson Lee commented Jul 10 '13, 9:24 p.m.

BTW, to avoid unnecessary impact to the system, we created an ACL for IVersionedContentService.

acl rtc_file url_regex -i ^https://proxy.domain:9443/ccm/service/*
range_offset_limit none rtc_file

Your answer

Register or to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.