| Index | Alphabetical Index |
Option Name: | request_header_add |
---|---|
Replaces: | |
Requires: | |
Default Value: | none |
Suggested Config: |
|
Usage: request_header_add field-name field-value acl1 [acl2] ... Example: request_header_add X-Client-CA "CA=%ssl::>cert_issuer" all This option adds header fields to outgoing HTTP requests (i.e., request headers sent by Squid to the next HTTP hop such as a cache peer or an origin server). The option has no effect during cache hit detection. The equivalent adaptation vectoring point in ICAP terminology is post-cache REQMOD. Field-name is a token specifying an HTTP header name. If a standard HTTP header name is used, Squid does not check whether the new header conflicts with any existing headers or violates HTTP rules. If the request to be modified already contains a field with the same name, the old field is preserved but the header field values are not merged. Field-value is either a token or a quoted string. If quoted string format is used, then the surrounding quotes are removed while escape sequences and %macros are processed. In theory, all of the logformat codes can be used as %macros. However, unlike logging (which happens at the very end of transaction lifetime), the transaction may not yet have enough information to expand a macro when the new header value is needed. And some information may already be available to Squid but not yet committed where the macro expansion code can access it (report such instances!). The macro will be expanded into a single dash ('-') in such cases. Not all macros have been tested. One or more Squid ACLs may be specified to restrict header injection to matching requests. As always in squid.conf, all ACLs in an option ACL list must be satisfied for the insertion to happen. The request_header_add option supports fast ACLs only. |
|
| Index | Alphabetical Index |