On Tue, 2020-02-18 at 20:35 +0100, Michael Osipov wrote: > Am 2020-02-18 um 10:07 schrieb Oleg Kalnichevski: > > On Mon, 2020-02-17 at 21:28 +0100, Michael Osipov wrote: > > > Folks, > > > > > > I have continued to fiddle a bit more with the redirector in > > > HttpClient > > > 5.0. I have modified my servlet code to respond with 307 from > > > within > > > a > > > Tomcat valve which immediately kicks in after "Expect: 100- > > > continue". > > > > > > There seems to be a bug in RedirectExec: > > > > > > > ... > > > > > The client is sending the body "I am a checksum" also 100 has not > > > been > > > issued, but 307. I have expected the client to follow the > > > redirect > > > and > > > retry. The request fails at the end because the HTTP entity has > > > already > > > been consumed. > > > > > > Ideas? > > > > > > Michael > > > > > > > Hi Micheal > > > > I presume you no longer remember this discussion: > > > > https://issues.apache.org/jira/browse/HTTPCORE-411 > > > > HttpClient 5.0 behaves differently compared to 4.x with regards to > > the > > expect-continue handshake. What you are seeing is what is believed > > to > > be RFC 7230 conformant behavior (not that I am very happy about > > it). > > > > What we could do, though, in this particular case is to disregard > > the > > spec requirement given that the origin server has signaled its > > intention to close the connection after the redirect by sending > > `Connection: close` response header. > > Nuts, I re-read the issue, but it was about chunked encoding. I did > not > use chunked TE. I have provided a content-length. Morever, the > subject > of that issue refers to RFC 2616. > > I don't understand why the body has to be send before the first > status > code is received. rfc7231#section-5.1.1 clearly says: > > > > > o A client that sends a 100-continue expectation is not > > required to > > wait for any specific length of time; such a client MAY > > proceed to > > send the message body even if it has not yet received a > > response. > > Furthermore, since 100 (Continue) responses cannot be sent > > through > > an HTTP/1.0 intermediary, such a client SHOULD NOT wait for > > an > > indefinite period before sending the message body. > > > It says MAY. So we don't have to send the request body before the > 100 > status. > > Can you point to the spot of the spec which caused the change? I > don't > get it. > I believe that we still can send the body AFTER 100 and are still > compliant. Otherwise expect continue is pointless from my POV and > has > the very same effect as not using it. > > Michael >
Michael The client MUST send the request body matching the request head with `Content-Length` header in response to 307 status in order to comply with the spec. After that the entity is spent and cannot be repeated. Hope this helps Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
