The question keeps coming up: Why doesn’t BIG-IP support internet content adaptation protocol (ICAP) 204 response? (meaning beyond the preview, as would be indicated to the server by the optional "Allow: 204" header). Detailed explanations are below, with sequence diagrams to support the explanations following.
Does BIG-IP support the "204 no-content" response from an ICAP server.
Yes, as long as it is within or immediately following the preview. BIG-IP is an ICAP client. After the preview has been sent, BIG-IP awaits a response from the server. If it is 204, BIG-IP will replay its preview to the HTTP client or server instead of awaiting a response from the ICAP server. If it is "200 ok" or "100 continue", BIG-IP will drop its preview and stream the response from the ICAP server as it arrives.
Why doesn't BIG-IP support ICAP "Allow: 204" so that a "204 no-content" response can be issued by the ICAP server at any time?
The ability to accept 204 after the server has responded to the preview, is an optional client capability that must be announced by the client with an “Allow: 204” header in the request to the server. Whether to support it is explicitly left to the client “because it imposes a burden on the client of buffering the entire message” (RFC 3507 section 4.6). Since BIG-IP is not a storage device and handles many connections concurrently (not all ICAP) with finite memory, it cannot support unbounded buffering. Even a single ICAP message can be gigabytes long (e.g. video) so an attempt to buffer beyond a well-defined (smallish) preview could exhaust memory and crash the entire BIG-IP, depending on what the ICAP server does (which we have no control over). Therefore we do not support "Allow: 204" and do not announce it.
What if I use an iRule to add the "Allow: 204" header to the ICAP request?
Using the iRule command "ICAP::header add Allow 204" in the ICAP_REQUEST event will insert the header "Allow: 204" into the ICAP request, but will not affect the behavior of the Big-IP as an ICAP client. It will not enable the desired functionality. It will, however, misinform the ICAP server into thinking the client can accept 204 outside of the preview. When the server responds with 204 outside the preview, the Big-IP ICAP client will (correctly) treat it as an error and reset the ICAP connection. It will also report an error to ADAPT which will perform its service-down-action, having already dropped its copy of the preview. The ICAP server will have stopped streaming the response payload, and that data will be lost.
Can Internal Virtual Servers be assigned to a route-domain?
The clientside of an IVS is referred to by name and does not have a destination address at all, therefore there is no restriction on the route domain. Internally, the IVS is a virtual server in which the destination is ignored, but it still has the destination fields (which have value 0 and are ignored).
Is there any reason to doubt that Internal VSs will work with route-domains?
The server side is the same as any other VS. The client side has no destination, therefore no route domain.
Sequence Diagrams
Normal request modification with preview
Request modification with 204 response to preview
Request modification with 204 response beyond preview (Unsupported)
Normal response modification with preview
Response modification with 204 response to preview
Response modification with 204 response beyond preview (Unsupported)
I'm troubleshooting an icap / asm issue and i'm seeing the F5 send an Allow: 204 in the icap request. but the text above states " we do not support "Allow: 204" and do not announce it". I'm I not reading the wireshark trace correctly or I'm I missing something ?
