Disable partial GET request in client/server side?
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
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. https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=201208 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. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.3 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. and 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
Comments
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
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.
Comments
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/com.ibm.team.scm.common.IVersionedContentService/content/com.ibm.team.filesystem/FileItem/_pbsCsMEFEeKM4aepnKXERg/_Mp5qpODIEeKxk-h3JWJymg/bRqsAAfsJ2HaJClkCWCY15VspCc3RQ1IUjakTZGC49o
|
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. Comments
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.
Never worked with the range_offset_limit parameter before. After reviewing http://www.squid-cache.org/Doc/config/range_offset_limit/ looks to be a cool solution. By setting this, did you see any indication of improved performance.
|
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.