-
Notifications
You must be signed in to change notification settings - Fork 103
Modify HTTP Messages
TempestaFW can modify, add and remove HTTP headers before forwarding messages to recipient. Both request and response messages can be modified. User is responsible for correctness of HTTP message after the modifications. Although it's possible to modify any header, the modification took place just before transmitting and no additional HTTP headers validation happen.
Directives for modifying responses and requests have the same syntax which is described below.
Append a new header to HTTP message before forwarding it:
resp_hdr_add <NAME> <VALUE>;
req_hdr_add <NAME> <VALUE>;
NAME
- Header name;
VALUE
- Value of header.
Existing headers with the same name won't be removed or modified, instead a new header will be added with the user
defined value.
Example:
With directive resp_hdr_add Cache-Control "no-cache";
:
- already existing header
Cache-Control: no-store
will be updated toCache-Control: no-store, no-cache
; - if
Cache-Control
header is not found in response, a new headerCache-Control: no-cache
will be added.
Modify an existing header of HTTP message before forwarding it:
resp_hdr_set <NAME> <VALUE>;
req_hdr_set <NAME> <VALUE>;
NAME
- Header name;
VALUE
- Value of header, optional.
Unlike req_hdr_add
, all existing headers of the same name are removed from the message and, if VALUE
is specified, a new header with the specified VALUE
is added.
Example:
With directive resp_hdr_set Cache-Control "no-cache";
:
- already existing header
Cache-Control: no-store
will be replaced byCache-Control: no-cache
; - if
Cache-Control
header is not found in response, a new headerCache-Control: no-cache
will be added.
With directive resp_hdr_set Cache-Control;
:
- already existing header
Cache-Control: no-store
will be removed; - if
Cache-Control
header is not found in response, no modifications will happen.
A usage example to implement HTTP Strict Transport Security
resp_hdr_set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Up to 64 directives (64 modifications) may be specified for each of request and response. The directives can be grouped by locations as defined in the Locations section.
- Home
- Requirements
- Installation
-
Configuration
- Migration from Nginx
- On-the-fly reconfiguration
- Handling clients
- Backend servers
- Load Balancing
- Caching Responses
- Non-Idempotent Requests
- Modify HTTP Messages
- Virtual hosts and locations
- HTTP Session Management
- HTTP Tables
- HTTP(S) Security
- Header Via
- Health monitor
- TLS
- Virtual host confusion
- Traffic Filtering by Fingerprints
- Run & Stop
- Application Performance Monitoring
- Use cases
- Performance
- Contributing