[
https://issues.apache.org/jira/browse/TS-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13501269#comment-13501269
]
Leif Hedstrom commented on TS-1058:
-----------------------------------
Wow, I'm so sorry, I can't believe this has been sitting here for almost a
year. Yakov, is this patch still relevant? My main concern is that I'm not sure
I understand the use case here, and why the server is not doing keep-alive when
it should? It makes me wonder if there's a bug somwehere in the keep-alive
logic, and if so, adding this API seems like a bandaid? :)
> 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
> Assignee: Leif Hedstrom
> Labels: patch
> Fix For: 3.3.1
>
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira
