On Wed, 2020-02-19 at 21:19 +0100, Michael Osipov wrote: > Am 2020-02-18 um 22:29 schrieb Oleg Kalnichevski: > > 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. > > Please call me stupid, but I would like to read the *MUST* in the > RFC > for that. I still cannot wrap my head around that making this > feature > mostly useless. >
I have been saying all along in the course of HTTPCORE-411 argument. There is no clear statement in RFC 7230 with regards to handling of request entity during the expect-continue handshake. There is however a clarification from Roy T Fielding quoted in the ticket. Based on the current interpretation of RFC 7230 the expect-continue handshake is pretty much useless for `Content-Length` delimited requests. > Can we pick up your idea: > >>> 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. > > and react on the close *before* sending the body even if we have > provided a content length? > We can look into that in 5.1. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
