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