You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Sudheer Vinukonda (JIRA)" <ji...@apache.org> on 2014/05/11 00:03:42 UTC

[jira] [Commented] (TS-2791) POST transactions failing with ERR_CLIENT_ABORT

    [ https://issues.apache.org/jira/browse/TS-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13994113#comment-13994113 ] 

Sudheer Vinukonda commented on TS-2791:
---------------------------------------

So, the race condition seems to be with the code below. It looks like there's a header_done flag to guard against sending the client response too soon. But, that may be an issue with POST requests. When I removed that flag, the POST requests (even large ones) are now successful. Am considering enhancing the API below to not check for header_done for POST requests towards origin.

{code}
--- a/proxy/FetchSM.cc  2014-05-10 01:42:07.006063763 +0000
+++ b/proxy/FetchSM.cc  2014-05-10 01:43:56.714348545 +0000
@@ -532,8 +532,10 @@
   // Before header_done, FetchSM may not 
   // be initialized.
   //  
-  if (header_done)
+  //if (header_done) {
     write_vio->reenable();
+    fetch_handler(TS_EVENT_VCONN_WRITE_READY, write_vio);
+  //}
 
   if (header_done && (fetch_flags & TS_FETCH_FLAGS_NEWLOCK)) {
     MUTEX_UNTAKE_LOCK(mutex, this_ethread());
{code}

> POST transactions failing with ERR_CLIENT_ABORT
> -----------------------------------------------
>
>                 Key: TS-2791
>                 URL: https://issues.apache.org/jira/browse/TS-2791
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: SPDY
>            Reporter: Sudheer Vinukonda
>              Labels: spdy, yahoo
>
> During our production testing of SPDY, we noticed that when trying to compose mails (POST transactions) on Firefox, we are seeing "Network Error" from the browser and ERR_CLIENT_ABORT from squid.logs. Upon some analysis, this issue appears to be likely specific to SPDY transactions and seem to be triggered by the expiry of proxy.config.http.transaction_no_activity_timeout_in timer. 
> After some investigation, it looks like this may be caused by a timing issue related to streaming of the POST data to the origin.. If the POST body (data) is available by the time client session and origin connection is ready, the POST is successful, but, if the data is large enough that it is not all read yet by the time origin connection is established, the streaming does not get triggered. Debugging further to identify the root cause.



--
This message was sent by Atlassian JIRA
(v6.2#6252)