[
https://issues.apache.org/jira/browse/TS-3777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14682171#comment-14682171
]
Sudheer Vinukonda edited comment on TS-3777 at 8/11/15 5:58 PM:
----------------------------------------------------------------
Just from the top of my head, it seems like a pretty common scenario for this
to happen with chunked encoding (when the origin returns an error while the
post body is still being received from the client) ?
"it seems there must be post cases, that send extra data after the response
header and the advertised content length. "
Also, FWIR, this was a memory leak fix for this exact scenario in YTS days
(below's the description from the internal bug - let me know if you need the
link to the internal bug and I can provide that offline).
{code}
If YTS detects an error after reading client request headers but before
completing the POST body tunnel, it writes the response to the client
immediately and closes the connection. This can happen for example when we get
a DNS error trying to resolve the origin host, or if a plugin reenables the SM
with error in READ_REQUEST_HEADER.
When we close the connection early, the kernel sends a TCP RST to the client
because there is still data in the receive queue. Although sending reset is
technically valid, some clients (including YTS itself before fix for bug
2572172) may not process the response correctly.
Ideally we should keep the connection open and read all the data from the
client before closing. It is debatable whether we should send the response
before or after finishing the post body read (squid sends response immediately,
akamai seems to wait for POST to complete before sending response).
{code}
[~zwoop], [~bcall] may have more info (traces etc) if you need them (although,
I just think this is nothing but a very basic error scenario in POST with
chunked encoding)
was (Author: sudheerv):
Just from the top of my head, it seems like a pretty common scenario for this
to happen with chunked encoding (when the origin returns an error while the
post body is still being received from the client) ?
"it seems there must be post cases, that send extra data after the response
header and the advertised content length. "
Also, FWIR, this was a memory leak fix for this exact scenario in YTS days
(below's the description from the internal bug - let me know if you need the
link to the internal bug and I can provide that offline).
{code}
If YTS detects an error after reading client request headers but before
completing the POST body tunnel, it writes the response to the client
immediately and closes the connection. This can happen for example when we get
a DNS error trying to resolve the origin host, or if a plugin reenables the SM
with error in READ_REQUEST_HEADER.
When we close the connection early, the kernel sends a TCP RST to the client
because there is still data in the receive queue. Although sending reset is
technically valid, some clients (including YTS itself before fix for bug
2572172) may not process the response correctly.
Ideally we should keep the connection open and read all the data from the
client before closing. It is debatable whether we should send the response
before or after finishing the post body read (squid sends response immediately,
akamai seems to wait for POST to complete before sending response).
{code}
> TSHttpConnect and POST request does not fire TS_VCONN_READ_COMPLETE nor
> TS_VCONN_EOS
> ------------------------------------------------------------------------------------
>
> Key: TS-3777
> URL: https://issues.apache.org/jira/browse/TS-3777
> Project: Traffic Server
> Issue Type: Bug
> Components: TS API
> Reporter: Daniel Vitor Morilha
> Assignee: Susan Hinrichs
> Labels: yahoo
> Fix For: 6.1.0
>
>
> When using TSHttpConnect to connect to ATS itself (internal vconnection),
> sending a POST request and receiving a CHUNKED response. ATS does not fire
> neither TS_VCONN_READ_COMPLETE nor TS_VCONN_EOS.
> Trying to close the vconnection from the plug-in after receiving the last
> chunk ("\r\n0\r\n") results into the PluginVC repeating the following message:
> {noformat}
> [Jul 14 21:24:06.094] Server {0x7ffff7fbe800} DEBUG: (pvc_event) [0] Passive:
> Received event 1
> {noformat}
> I am glad to provide an example if that helps.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
