Thanks Martin . Our expectation Is that , on receiving a RST_STREAM with CANCEL or NO_ERROR from the client after 1.5 secs for a particular stream , we don’t want the connection to be closed with a GOAWAY:NO_ERROR (while trying to send response after 2secs asynchronously over a stream that is closed) as the other streams during the same time are processing data fine .
Additional info for GOAWAY: Connection [], Stream[],An error occurred during processing that was fatal to the connection . Thanks and Regards Arshiya Shariff -----Original Message----- From: Martin Grigorov <mgrigo...@apache.org> Sent: Tuesday, September 22, 2020 7:31 PM To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: HTTP2: Tomcat sends GOAWAY when trying to respond over a stream where the client has already sent RST_STREAM:NO ERROR Hi, On Tue, Sep 22, 2020 at 1:47 PM Arshiya Shariff <arshiya.shar...@ericsson.com.invalid> wrote: > Thank you so much Martin for the response. > Yes , 9.0.38 testing is on going . > > As we don’t get this clear with the RFC , please help us with the > below two cases : * If a client sends RST_STREAM with NO_ERROR, then while sending async > response is it expected behavior to close connection with GOAWAY ? > * If a client sends RST_STREAM with CANCEL , then while sending > async response will tomcat send RST_STREAM or GOAWAY , from http2 > protocol perspective ? > As per https://tools.ietf.org/html/rfc7540#section-6.4 and https://tools.ietf.org/html/rfc7540#section-5.1 if "send R" or "recv R" are processed then the stream is moved to CLOSED state. GOAWAY should be sent to the client only if the connection will be closed ( https://tools.ietf.org/html/rfc7540#section-6.8). The server should close the connection only if some serious problem has happened, e.g. an IOException. Tell us more about your use case. What do you want to do when 1.5secs pass ? What do you expect to happen ? > > Thanks and Regards > Arshiya Sharif > > -----Original Message----- > From: Martin Grigorov <mgrigo...@apache.org> > Sent: Tuesday, September 22, 2020 1:18 AM > To: Tomcat Users List <users@tomcat.apache.org> > Subject: Re: HTTP2: Tomcat sends GOAWAY when trying to respond over a > stream where the client has already sent RST_STREAM:NO ERROR > > Hi, > > On Mon, Sep 21, 2020 at 7:56 PM Arshiya Shariff < > arshiya.shar...@ericsson.com.invalid> wrote: > > > Hi All, > > > > The client has configured a response timeout of 1.5 seconds. In a > > case when our application tries to respond over a http2 stream > > asynchronously after 2 seconds where the client has already sent > > RST_STREAM with NO ERROR in 1.5 seconds > > > Why does the client send NO_ERROR to the server ? I think it should > send a CANCEL instead. > https://tools.ietf.org/html/rfc7540 mentions NO_ERROR only for > "Graceful shutdown of the server". > > > > (due to no response) , then tomcat sends GOAWAY and closes the HTTP2 > > connection . Is this behavior of GOAWAY and connection closure expected ? > > We have planned to upgrade to Embedded tomcat version 9.0.38 . These > > are the behaviors we see in production with version 9.0.22 , so we > > need some help with analyzing / validating the existing behavior > > before > the upgrade . > > Please let us know. > > > > Friendly advice: > Please setup 9.0.38 locally and test on it. > 9.0.22 is way too old. It is up to you to use it for your production > but for reporting bugs it is recommended to use the latest available version. > I, personally, prefer to spend my spare time with my family and > friends than to debug old versions just because the user doesn't > bother to test on a newer version. > > > > > > Thanks and Regards > > Arshiya Shariff > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
