You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Leif Hedstrom (Updated) (JIRA)" <ji...@apache.org> on 2012/01/08 22:42:39 UTC

[jira] [Updated] (TS-1058) Intercept an HTTP client's request

     [ https://issues.apache.org/jira/browse/TS-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Leif Hedstrom updated TS-1058:
------------------------------

    Fix Version/s:     (was: 3.1.2)
                   3.1.3
    
> Intercept an HTTP client's request
> ----------------------------------
>
>                 Key: TS-1058
>                 URL: https://issues.apache.org/jira/browse/TS-1058
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: TS API
>    Affects Versions: 3.1.1
>            Reporter: Yakov Kopel
>              Labels: patch
>             Fix For: 3.1.3
>
>         Attachments: patch.diff
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> I want that the trafficserver will give the client the response instead of the server.
> The trafficserver offers the INKHttpTxnIntercept api to do so, but it is not so convenience to use it.
> I want to use the regular flow of the trafficserver, and its regular parsing commands.
> The trafficserver's plugins examples also aren't using the INKHttpTxnIntercept , but they rather using the "rasing error" method, and then they response the request at the response hook.
> So, this is whta i did.
> On the global-hook at the TS_EVENT_HTTP_READ_REQUEST_HDR i raised TS_EVENT_HTTP_ERROR.
> I also added TS_HTTP_SEND_RESPONSE_HDR_HOOK and there i returned http response with the KEEP-ALIVE header.
> The problem is that the trafficserver is closing the connection although i added to the response the KEEP-ALIVE header.
>  
> When the Trafficserver is trying to send response to the client, it terminate the session after it.
> Although I added the "KEEP-ALIVE" mime field - it didn't work.
> The debug dump is looking like this:
>   [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4] [&HttpSM::state_api_callback, HTTP_API_CONTINUE]
>   [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4] [&HttpSM::state_api_callout, HTTP_API_CONTINUE]
>   [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect) [HttpSM::do_redirect]
>   [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect) [HttpTunnel::deallocate_postdata_copy_buffers]
>   [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4] adding producer 'internal msg'
>   [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4] adding consumer 'user agent'
>   [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) tunnel_run started, p_arg is NULL
>   [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4] consumer_handler [user agent VC_EVENT_WRITE_COMPLETE]
>   [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4] [&HttpSM::tunnel_handler_ua, VC_EVENT_WRITE_COMPLETE]
>   [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_cs) [4] session closed
>   [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_cs) [4] session destroy
>   [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4] [HttpSM::main_handler, HTTP_TUNNEL_EVENT_DONE]
>   [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4] [&HttpSM::tunnel_handler, HTTP_TUNNEL_EVENT_DONE]
>   [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect) [HttpTunnel::deallocate_postdata_copy_buffers]
>   [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4] calling plugin on hook TS_HTTP_TXN_CLOSE_HOOK at hook 0x3B97610
> The Solution:
> I'm adding a patch of functino that rasing the internal flag of KEEP-ALIVE, so the trafficserver will realy believe us that we want to keep this connection alive :)
> Example for the usage of the new function:
>   // Tell the trafficserver to not close this connection (keep-alive)
>   TSHttpTxnCloseAfterResponse(txnp, 0);

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira