Hello, It was good to meet everyone at the summit in Sunnyvale.
I raised this question with a few people at the summit. I'm writing a content-scanning plug-in that must block requests and return a 403 response depending on the URL or content of the request. The people I spoke to directed me towards the TSHttpTxnIntercept() API function. This allows a plug-in to take over responsibility for servicing a request i.e. the plug-in can return its own response, so at first I was very hopeful, it seemed to be just what I needed. I've hit a problem however. The TSHttpTxnIntercept() function, according to the documentation, can only be called from the TS_HTTP_READ_REQUEST_HDR_HOOK. That's fine for GET requests where the decision to allow or block the request is based purely on the URL, but it gives me a problem for POST requests where the decision can be based on the content of the POST message. At the point this hook is called the POST content is not available so my plug-in has no choice but to intercept the transaction just in case it needs to be blocked. This means the plug-in has to service all POST requests itself which is clearly unsatisfactory. (Having intercepted a transaction there doesn't seem to be a way to cancel the intercept later.) Is there a better way for a plug-in to intercept a POST request and return its own response? This raises the question of whether it is even possible for a plug-in to buffer-up the POST data and prevent it being forward to the origin server until the plug-in has received the complete message from the client and scanned it. The documentation for transformation plug-ins (specifically for Sample Buffered Null Transform Plugin) describes how a plug-in can buffer-up response data and process it before allowing it to flow to the client but it doesn't mention request data. Is it possible for a plug-in to buffer up POST data and prevent it flowing to the server until the plug-in has received the entire message from the client? Many thanks for your help, Rob Maidment
