You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Further development of #511 (HTTP: transform custom HTTP headers). Depends on the new rule syntax introduced in #731 (HTTP tables) and #531 (Upgrade/downgrade HTTP messages).
A use case (for Wiki)
If several of the backend servers in the WAF acceleratiotn scenario have public IPs and allow HTTP/1.0, then, even announcing the public IPs as virtual IPs (VIPs) on Tempesta FW intefaces, the WAF, configured in reverse proxy mode, doesn't have an idea which backend to send an HTTP/1.0 requests to. The Internet adopts HTTP/3 nowadays, so there is no sense to care about HTTP/1.0.
Conditional HTTP upgrade
The first solution is to upgrade forwarded HTTP/1.0 request without Host header to HTTP/1.1 or HTTP/2 with correct setting of Host header. We can do this using a rule to translate the backend public IP to it's Host value (the condition construction is the subject got multi-pattern matching optimization in #732, so keep the further optimization in mind):
$dst_ip is the matching variable for skb destination IP address.
Setting X-Server-IP
Another solution is just to add an extension header with the backend public IP:
req_hdr_add X-Server-IP $dst_ip
and the the WAF to make the correct message forwarding based on the header.
The variables
Please research how the variables are implemented in Nginx, Varnish VCL, HAProxy.
Following variables must be implemented:
$proto - a protocol (HTTP/1.0, HTTP/1.1 etc) used by a client in a request;
$dst_addr - client skb destination address;
$dst_port - client skb destination port;
$src_addr - client skb source address;
Variables should be aggregated into tfw_http_req_t (most likely we'll have different sets of variables for requests and responses and there is no sense to spend extra memory) as an array of fixed size. The array items could be something like:
typedefstruct {
union {
TfwStr*str;
longi_val;
};
} TfwVar;
Further development of #511 (HTTP: transform custom HTTP headers). Depends on the new rule syntax introduced in #731 (HTTP tables) and #531 (Upgrade/downgrade HTTP messages).
A use case (for Wiki)
If several of the backend servers in the WAF acceleratiotn scenario have public IPs and allow HTTP/1.0, then, even announcing the public IPs as virtual IPs (VIPs) on Tempesta FW intefaces, the WAF, configured in reverse proxy mode, doesn't have an idea which backend to send an HTTP/1.0 requests to.The Internet adopts HTTP/3 nowadays, so there is no sense to care about HTTP/1.0.Conditional HTTP upgrade
The first solution is to upgrade forwarded HTTP/1.0 request without Host header to HTTP/1.1 or HTTP/2 with correct setting of Host header. We can do this using a rule to translate the backend public IP to it's Host value (the condition construction is the subject got multi-pattern matching optimization in #732, so keep the further optimization in mind):
$dst_ip
is the matching variable for skb destination IP address.Setting X-Server-IP
Another solution is just to add an extension header with the backend public IP:
req_hdr_add X-Server-IP $dst_ip
and the the WAF to make the correct message forwarding based on the header.
The variables
Please research how the variables are implemented in Nginx, Varnish VCL, HAProxy.
Following variables must be implemented:
$proto
- a protocol (HTTP/1.0
,HTTP/1.1
etc) used by a client in a request;$dst_addr
- client skb destination address;$dst_port
- client skb destination port;$src_addr
- client skb source address;Variables should be aggregated into
tfw_http_req_t
(most likely we'll have different sets of variables for requests and responses and there is no sense to spend extra memory) as an array of fixed size. The array items could be something like:References
The text was updated successfully, but these errors were encountered: