The Blacklist plugin sends "access forbidden" messages to
clients if their requests are directed to blacklisted hosts. Therefore,
the plugin needs a transaction hook so it will be called back when
Traffic Server’s HTTP state machine reaches the “send response header”
event. In the Blacklist plugin’s handle_dns
routine, the
transaction hook is added as follows:
INKMutexLock (sites_mutex); for (i = 0; i < nsites; i++) { if (strncmp (host, sites[i], host_length) == 0) { printf ("blacklisting site: %s\n", sites[i]); INKHttpTxnHookAdd (txnp, INK_HTTP_SEND_RESPONSE_HDR_HOOK, contp); INKHandleStringRelease (bufp, url_loc, host); INKHandleMLocRelease (bufp, hdr_loc, url_loc); INKHandleMLocRelease (bufp, INK_NULL_MLOC, hdr_loc); INKHttpTxnReenable (txnp, INK_EVENT_HTTP_ERROR); INKMutexUnlock (sites_mutex); return; } } INKMutexUnlock (sites_mutex); done: INKHttpTxnReenable (txnp, INK_EVENT_HTTP_CONTINUE); }
This code fragment shows some interesting features. The plugin is comparing the requested site to the list of blacklisted sites. While the plugin is using the blacklist, it must acquire the mutex lock for the blacklist to prevent configuration changes in the middle of a blacklisting operation. If the requested site is blacklisted, then the following things happen:
A transaction hook is added with
INKHttpTxnHookAdd
; the plugin is called back
at the “send response header” event (i.e., the plugin sends an Access
forbidden
message to the client). You can see that in order to
add a transaction hook, you need a handle to the transaction being
processed.
The transaction is reenabled using
INKHttpTxnReenable
with
INK_EVENT_HTTP_ERROR
as its event argument.
Reenabling with an error event tells the HTTP state machine to
stop the transaction and jump to the “send response header” state.
Notice that if the requested site is not blacklisted, then the
transaction is reenabled with the
INK_EVENT_HTTP_CONTINUE
event.
The string and INKMLoc
data stored in
the marshal buffer bufp
is released by
INKHandleStringRelease
and
INKHandleMLocRelease
(see Release Marshal Buffer Handles). Release these handles before
reenabling the transaction.
In general, whenever the plugin is doing something to a
transaction, it must reenable the transaction when it is finished. In other words: every time your handler function handles a transaction
event, it must call INKHttpTxnReenable
when it is
finished. Similarly, after your plugin handles session events
(INK_EVENT_HTTP_SSN_START
and
INK_EVENT_HTTP_SSN_CLOSE
), it must reenable the session
with INKHttpSsnReenable
. Reenabling the transaction twice in the same plugin routine is a
bad error.