ltm rule namespace ADAPT

iRule(1)						BIG-IP TMSH Manual						  iRule(1)

ADAPT
       Namespace ADAPT

DESCRIPTION
       iRule commands and events for working with content adaptation.

       ADAPT* events can take any ADAPT, HTTP, SSL, or TCP commands, except:
	   * The ADAPT::result command can only be used in ADAPT* events.
	   * The ADAPT commands (except ADAPT::result) can be used
	     only in HTTP_REQUEST and HTTP_RESPONSE events.

       ADAPT iRule commands apply to adaptations on the client side of the connection (request adaptations) or the server side of
       the connection (response adaptation). A command may optionally specify to which side it applies (request|response),
       otherwise it applies to the current side which is the side of the event in which it is being executed.  The iRule commands
       modify the profile attributes for the current connection flow only. Each new connection begins with the attributes
       configured in the profile via tmsh or the GUI.

       Modifications to the response side from a request side event are held pending until the server side connection has been
       established.

       Dynamic Adaptation Contexts

       The ADAPT filter can support multiple adaptations in a single connection flow by means of dynamic adaptation contexts. Each
       adaptation is described by a context which has all the attributes of a request-adapt or response-adapt profile. One or more
       contexts may be chained so that their adaptations are applied to a connection flow in sequence. When an adapt profile is
       initially configured on the request (client) or response (server) side of a virtual server, it has a single context called
       the static context. This represents the initial configuration of the adapt profile.

       Dynamic contexts may be created by internal BigIP features (such as PEM service chaining) or by ADAPT::context_create
       commands.  These exist only on the connection flow in which they are created.  When the first dynamic context is created,
       it replaces the static context, inheriting all its attributes. Thus the static context becomes a template for all dynamic
       contexts created in the same connection flow on that side of the virtual server. Subsequently created contexts are added in
       a series so that their adaptations are performed one after another (details are described under the ADAPT::create command).

       The first dynamic context (and possibly more) is created before the ADAPT filter, usually in the HTTP_REQUEST event
       (contexts may only be created in request (client) side events, even if they are response (server) side contexts. After each
       dynamic adaptation context is applied, the appropriate ADAPT_REQUEST_* or ADAPT_RESPONSE_* events are triggered. During the
       ADAPT_REQUEST_* events it is possible for an iRule to decide, based on the results of previous adaptations, whether to
       create and configure another context and pass the flow through it. Thus adaptation chains my be created dynamically during
       a connection flow.

       When the connection flow terminates, all dynamic contexts are deleted on both side of the virtual server. There is also a
       command to delete all dynamic contexts.

       For the purpose of iRules, each adaptation context is represented by an opaque handle that is provided when the context is
       created, and may be applied to other commands to affect that context. The scope of a handle is the virtual server in which
       it was obtained.  A handle to the static context may also be obtained. Each context has a name specified when it is
       created, which may be retrieved via the handle and is useful for debug logging. A static context has the name of the
       corresponding profile. Within an iRule event there is a current context which is the one executing (if it is in an ADAPT
       event) or the next one that will execute (if the event is outside ADAPT). The current context may be queried and used to
       make decisions based on which context is executing.

       In any command where a context handle is specified, any side also specified must match that of the context or an error is
       raised. Best practice is not to specify a side when a context handle is specified. If no dynamic contexts have been
       created, the current context is the static context of the side to which the command applies (otherwise the static context
       serves only as a template for initializing dynamic contexts).

HINTS
SEE ALSO
BIG-IP							    2022-04-12							  iRule(1)