use "cachable" and "requestor" spellings

Author: MFTabriz

docs/ConfigExamples/Caching/WindowsUpdates.md

@@ -43,7 +43,7 @@ requests. Particularly when large objects are involved.
     Default value is a bit small. It needs to be somewhere 100MB or
 higher to cope with the IE updates.
 - **[range_offset_limit](http://www.squid-cache.org/Doc/config/range_offset_limit)**.
-    Does the main work of converting range requests into cacheable
+    Does the main work of converting range requests into cachable
     requests. Use the same size limit as
     [maximum_object_size](http://www.squid-cache.org/Doc/config/maximum_object_size)
     to prevent conversion of requests for objects which will not cache

docs/DeveloperResources/RequestUseCases.md

@@ -29,7 +29,7 @@ interact for a number of use cases.
 - Requests on a client side connection are owned by the connection.
 - The data source from the store or upstream to satisfy a connection
   is owned by the request.
-- Upstream requests are owned by the requester - the client request
+- Upstream requests are owned by the requestor - the client request
   when the request is not being diverted to the store, and the store
   when it is being copied to cache.
 - The server-side connection is owned by the OS - it must remain a
@@ -206,8 +206,8 @@ Socket - an fd on unix, a HANDLE on windows.
     request to read data.
 11. the client
 
-## Uncacheable request
+## Uncacheble request
 
 ## Tunnel request
 
-## Cacheable request
+## Cacheble request

docs/Features/CollapsedForwarding.md

@@ -20,7 +20,7 @@ for the same URI to be processed as one request to the backend server.
 Normally disabled to avoid increased latency on dynamic content, but
 there can be benefit from enabling this in accelerator setups where the
 web servers are the bottleneck but are reliable and return mostly
-cacheable information.
+cachable information.
 
 It was left out of [Squid-3.0](/Releases/Squid-3.0)
 due to time and stability constraints. The

docs/Features/ConnPin.md

@@ -25,7 +25,7 @@ servers using Microsoft Integrated Login (NTLM/Negotiate), it needs:
 - code to activate the tying when a stateful authentication layer is
   seen
 - code to mark the objects downloaded over a pinned connection
-  uncacheable
+  uncachable
 - code to add a header advertising this capability to clients
 
 The HTTP protocol extensions used to negotiate this is documented in

docs/Features/LinuxOptimizedIO.md

@@ -15,7 +15,7 @@ involving pipes: splice, tee and vmsplice
     pipe
 
 Those ***might*** be useful in different cases: respectively disk cache
-hit, cacheable miss and (probably) error pages. We need to verify that
+hit, cachable miss and (probably) error pages. We need to verify that
 the semantics are right, and what kind of compromises are required to
 implement them
 

docs/Features/PartialResponsesCaching.md

@@ -20,7 +20,7 @@ categories: WantedFeature
 (from the bug report): When range_offset_limit is set to -1, Squid
 tries to fetch the entire object in response to an HTTP range request.
 
-- **Bug**: The entire object is fetched even when it is not cacheable
+- **Bug**: The entire object is fetched even when it is not cachable
     (e.g. because it is larger than
     [maximum_object_size](http://www.squid-cache.org/Doc/config/maximum_object_size)
     or some other criteria).

docs/Http11Checklist.md

@@ -376,15 +376,15 @@ categories: [WantedFeature, Feature]
 |            |            | 351 | MUST | 14.8 | always revalidate responses with cache-control: s-maxage=0 | |
 |            |            | 352 | MUST | 14.9 | follow the cache-control header directives at all times | |
 |            |            | 353 | MUST | 14.9 | pass cache-control directives through to the next link in the message path (ie don't eat them) | |
-|            |            | 354 | MAY | 14.9.1 | cache responses with cache-control: public even of the header/method might not normally be cacheable | |
+|            |            | 354 | MAY | 14.9.1 | cache responses with cache-control: public even of the header/method might not normally be cachable | |
 |            |            | 355 | MUST NOT | 14.9.1 | cache responses with cache-control: private | |
 |            |            | 356 | MUST NOT | 14.9.1 | use responses with cache-control: no-cache to satisfy other requests without successful revalidation | ie auto GET to IMS is allowed |
 |            |            | 357 | MAY | 14.9.1 | use responses with cache-control: no-cache to satisfy other requests without successful revalidation if the no-cache directive includes field-names | |
 |            |            | 358 | MUST NOT | 14.9.1 | send the headers listed in responses with cache-control: no-cache (header…) to satisfy other requests without successful revalidation if the no-cache directive includes field-names | |
 |            |            | 359 | MAY | 14.9.2 | use no-store on requests or responses to prevent data storage | |
 |            |            | 360 | MUST NOT | 14.9.2 | store any part of a request or it's response if the cache-control: no-store directive was in the request | This directive applies to both non-shared and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it. |
 |            |            | 361 | MUST NOT | 14.9.2 | store any part of a response or the request that elicited it if the cache-control: no-store directive was in the response | This directive applies to both non-shared and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it. |
-|            |            | 362 | SHOULD | 14.9.3 | consider responses with an Expires value that is \<= the response date and no cache-control header field to be non-cacheable | |
+|            |            | 362 | SHOULD | 14.9.3 | consider responses with an Expires value that is \<= the response date and no cache-control header field to be non-cachable | |
 |            |            | 363 | MUST | 14.9.3 | mark stale responses with Warning 110 | |
 |            |            | 364 | MAY | 14.9.3 | have squid configurable to return stale responses even when not requested by clients but responses served MUST NOT conlict with other MUST or MUST NOT requirements | |
 |            |            | 365 | MUST NOT | 14.9.4 | use a cached copy to respond to a request with cache-control: no-cache or Pragma: no-cache | |
@@ -455,8 +455,8 @@ categories: [WantedFeature, Feature]
 |            |            | 430 | MUST | 14.42 | use the upgrade header in a response with status code 101 | |
 |            |            | 431 | MUST | 14.42 | include the Upgrade connection-token whenever we use the Upgrade header | |
 |            |            | 432 | SHOULD | 14.43 | for the client - include a user-Agent field in requests | |
-|            |            | 433 | SHOULD | 14.44 | include a Vary header on any cacheable response we generate that used server negotiation | |
-|            |            | 434 | MAY | 14.44 | for the 'server' include a vary header with a non-cacheable response the used server negotiation | |
+|            |            | 433 | SHOULD | 14.44 | include a Vary header on any cachable response we generate that used server negotiation | |
+|            |            | 434 | MAY | 14.44 | for the 'server' include a vary header with a non-cachable response the used server negotiation | |
 |            |            | 435 | MAY | 14.44 | assume the same response will be given by a server for future requests with the same request field values as those listed by the vary header in the response whilst the response is still fresh | |
 |            |            | 436 | MUST NOT | 14.44 | generate a \* value for a vary field | |
 |            |            | 437 | MUST | 14.45 | fill in the Via header | |

docs/KnowledgeBase/Benchmarks.md

@@ -45,7 +45,7 @@ This number was taken in a **controlled test environment**. It has
 nothing to do with the numbers someone would get in a production
 environment; it's just an estimate of how fast squid can be. Squid was
 configured to do no logging, no access control, and apachebench was used
-to hammer squid asking 10M times for a static, cacheable, 600-bytes long
+to hammer squid asking 10M times for a static, cachable, 600-bytes long
 document. Of the 4 cores, 3 were running a multi-worker squid, one was
 running ab over the loopback interface.
 
@@ -229,7 +229,7 @@ nothing to do with the numbers someone would get in a production
 environment; it's just an estimate of how fast squid can be. Squid was
 configured to do no logging and apachebench was used to hammer squid
 asking 250K times for a blocked url (leading to a 403 response with a
-location header) or with a cacheable, 16KB long document. Of the 4
+location header) or with a cachable, 16KB long document. Of the 4
 cores, 2 were running a multi-worker squid. The apache benchmark was run
 from another host and from the same host with similar results.
 

docs/KnowledgeBase/HierarchyControl.md

@@ -32,8 +32,8 @@ The various directives are evaluated in this order:
 
 The purpose of cache hierarchy is to maximize the chance of finding
 objects in siblings, so a set of heuristics is applied to try and
-determine in advance whether an object is likely to be cacheable. A few
-objects are **not** cacheable, and are thus **not** hierarchic. Those
+determine in advance whether an object is likely to be cachable. A few
+objects are **not** cachable, and are thus **not** hierarchic. Those
 are:
 
   - reload requests

docs/SquidFaq/CacheDigests.md

@@ -154,7 +154,7 @@ Every object referenced in the index in RAM is checked to see if it is
 suitable for addition to the digest.
 
 A number of objects are not suitable, e.g. those that are private, not
-cacheable, negatively cached etc. and are skipped immediately.
+cachable, negatively cached etc. and are skipped immediately.
 
 A *freshness* test is next made in an attempt to guess if the object
 will expire soon, since if it does, it is not worthwhile adding it to