You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficserver.apache.org by Andreas Wederbrand <an...@wederbrand.se> on 2020/11/20 14:15:38 UTC

ATS 7.1 as reverse proxy timeouts on POST after 30 seconds instead of 1800 seconds

Hi!

I'm running ATS 7.1 as a reverse proxy and one of our origins takes 30+
seconds occasionally. I thought that
*proxy.config.http.post_connect_attempts_timeout* would control that. It is
set to it's default of 1800 seconds (30 minutes!?) but we still see a 504
after 30 seconds.

Am I missing something? Am I looking at the wrong configuration?

Thanks.

Re: [E] ATS 7.1 as reverse proxy timeouts on POST after 30 seconds instead of 1800 seconds

Posted by Susan Hinrichs <sh...@verizonmedia.com>.
There are two kinds of timeouts involved.  One is the various
*connect_attempts_timeout.  This timeout only applies while the connection
to the origin is being established (e.g. TLS handshake or TCP three-way for
non-TLS).  Then the regular
proxy.config.http.transaction_no_activity_timeout_out applies while waiting
for the first byte and all other bytes exchanged with the origin.

But you are running 71.  The connect_timeouts may have been applied until
the first byte was received.  I think this was fixed to be the proper
connect timeout instead of TTFB timeout in the 8.x timeframe.  So in that
case any POST/PUT method requests would by default wait 1800 seconds for
the first byte to return.  All other methods would wait the time specified
in proxy.config.http.connect_attempts_timeout which appears to default to
30 seconds.

Susan

On Fri, Nov 20, 2020 at 8:16 AM Andreas Wederbrand <an...@wederbrand.se>
wrote:

> Hi!
>
> I'm running ATS 7.1 as a reverse proxy and one of our origins takes 30+
> seconds occasionally. I thought that
> *proxy.config.http.post_connect_attempts_timeout* would control that. It
> is set to it's default of 1800 seconds (30 minutes!?) but we still see a
> 504 after 30 seconds.
>
> Am I missing something? Am I looking at the wrong configuration?
>
> Thanks.
>