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				  2017-01-31			      iRule(1)