[GitHub] [trafficserver] sudheerv commented on a change in pull request #7309: Disable client inactivity timeout while server is processing POST request

[GitBox <gi...@apache.org>]

sudheerv commented on a change in pull request #7309:
URL: https://github.com/apache/trafficserver/pull/7309#discussion_r518222672



##########
File path: proxy/http/HttpSM.cc
##########
@@ -2008,28 +2008,13 @@ HttpSM::state_read_server_response_header(int event, void *data)
 
     // Now that we know that we have all of the origin server
     // response headers, we can reset the client inactivity
-    // timeout.  This is unlikely to cause a recurrence of
-    // old bug because there will be no more retries now that
-    // the connection has been established.  It is possible
-    // however.  We do not need to reset the inactivity timeout
-    // if the request contains a body (noted by the
-    // request_content_length field) because it was never
-    // canceled.
-    //
-
+    // timeout.
     // we now reset the client inactivity timeout only
     // when we are ready to send the response headers. In the
     // case of transform plugin, this is after the transform
     // outputs the 1st byte, which can take a long time if the
     // plugin buffers the whole response.
-    // Also, if the request contains a body, we cancel the timeout
-    // when we read the 1st byte of the origin server response.
-    /*
-       if (ua_txn && !t_state.hdr_info.request_content_length) {
-       ua_txn->get_netvc()->set_inactivity_timeout(HRTIME_SECONDS(
-       HttpConfig::m_master.accept_no_activity_timeout));
-       }
-     */
+    ua_txn->set_inactivity_timeout(HRTIME_SECONDS(t_state.txn_conf->transaction_no_activity_timeout_in));

Review comment:
       Hmm, inactivity timeout for the ua_txn that has a non-zero CL is actually being cancelled in line #1943 above. Seems like we are re-enabling it and then canceling in post tunnel? I'm curious to know why we need to re-enable the UA inactivity timeout here? 
   
   FWIW, we are not seeing this specific issue with POSTs, but that may be because our Edge Proxies that are ATS6 always send a CL (because they buffer the request body) when talking to our DC Proxies that are ATS9. Are your issues for POSTs that are chunked encoding and not having a CL header?




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org