On Thu, 2020-02-20 at 20:36 +0100, Michael Osipov wrote: > Am 2020-02-20 um 10:50 schrieb Oleg Kalnichevski: > > 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. > > I re-read Roy's answer: > > > > Yes. Either side can choose to close the connection, but the server > > can't see another request until it has read past the framing of the > > first request. Most servers choose to close the connection if the > > response is non-2xx because 100-continue is meant to abort the send > > when it is unwanted. > > My understanding is that if the server choses to close the > connection, > there is no need to send the request body. So it looks to me that in > this case we can close it and drop the body sending otherwise we need > to > send all bytes advertised with "Content-Lenth" even if it is waste... > > Moreover, we can freely close the connection in this case avoiding > to > lose the HttpEntity as I understand. This could be an client/request > config option. > > > > > 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. > > Good. Shall I create a ticket for that? >
Yes, please. Raise an improvement request for HttpCore 5.1 Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
