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.
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?
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
