On 27/05/2020 10:59, Osipov, Michael wrote: > > > Am 2020-05-27 um 10:51 schrieb Mark Thomas: >> On 22/05/2020 22:59, Osipov, Michael wrote: >> >> <snip/> >> >>> I found one issue with HttpClient and Tomcat via HTTP/1.1. I have >>> decrypted the TLS traffic [1]. I can see that HttpClient sends the >>> headers also with a 4 KiB large chunk of the ZIP file. In return a >>> Tomcats send the 401 response with: >>>> Keep-Alive: timeout=300 >>>> Connection: keep-alive >>> >>> The client keeps sending in 8 KiB large blocks. After 2 134 016 written >>> bytes there is a TLS alert: Close Notify. A few packets later: RST. >>> >>> I would expect to see here: "Connection: close". >> >> Why? >> >> Does the client provide a content-length header and no expectation? If >> so, Tomcat could determine that the maxSwallowSize is going to be >> exceeded and close the connection early. > > Yes, it does. CL present and not expectation. A transcript is here [1]. > We have already a working patch for the early response, also Oleg is > already working on the early close not happening which is a bug in > HttpClient. > > As for the connection header: I do not understand why you assume the > header is no necessary. Your reasoning is that if the server closes the > physical connection before the client has spooled the entire body and it > is imperative for the client to close the connection too regard of the > presense of the header?
I didn't assume the header is not necessary. I asked for further explanation from you of why you thought it was necessary. I also asked some questions relevant to a potential justification for adding the header. Tomcat has enough information to know that: - it needs to return a 401 - the request body won't be read (by the application) - the request body is larger than maxSwallowSize so once that many bytes have been swallowed, Tomcat is going to close the connection At this point I think we are heading outside of behaviour defined by the HTTP/1.1 specification. I haven't found language covering aborted uploads. RFC 7230, 6.6 states a "Connection: close" header SHOULD be sent if Tomcat knows it is going to close the connection. I think that applies in this case so I'd be in favour of adding that behaviour. This then opens up an interesting question of whether to bother reading *any* of the request body if Tomcat knows it is going to close the connection before reading all of it. Based on what you have observed, would earlier closure of the connection (after a response with a "Connection: close" header) create additional difficulties? Would those clients that currently read the response while Tomcat is swallowing the first 2MB of upload still read the response if Tomcat didn't swallow any of the request? I think you can test this with maxSwallowSize="0" Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
