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						      2020-06-23					     iRule(1)