You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Michael Osipov <mi...@apache.org> on 2020/02/17 20:28:19 UTC
Possible bug in RedirectExec in HttpClient 5.0-beta7
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:
> [main] DEBUG org.apache.hc.client5.http.headers - http-outgoing-0 >> PUT /bb/repo/my.file HTTP/1.1
> [main] DEBUG org.apache.hc.client5.http.headers - http-outgoing-0 >> Accept-Encoding: gzip, x-gzip, deflate
> [main] DEBUG org.apache.hc.client5.http.headers - http-outgoing-0 >> Content-Length: 15
> [main] DEBUG org.apache.hc.client5.http.headers - http-outgoing-0 >> Content-Type: application/octet-stream
> [main] DEBUG org.apache.hc.client5.http.headers - http-outgoing-0 >> Host: localhost:8080
> [main] DEBUG org.apache.hc.client5.http.headers - http-outgoing-0 >> Connection: keep-alive
> [main] DEBUG org.apache.hc.client5.http.headers - http-outgoing-0 >> User-Agent: Apache-HttpClient/5.0-beta7-SNAPSHOT (Java/1.7.0_252)
> [main] DEBUG org.apache.hc.client5.http.headers - http-outgoing-0 >> Expect: 100-continue
> [main] DEBUG org.apache.hc.client5.http.wire - http-outgoing-0 >> "PUT /bb/repo/my.file HTTP/1.1[\r][\n]"
> [main] DEBUG org.apache.hc.client5.http.wire - http-outgoing-0 >> "Accept-Encoding: gzip, x-gzip, deflate[\r][\n]"
> [main] DEBUG org.apache.hc.client5.http.wire - http-outgoing-0 >> "Content-Length: 15[\r][\n]"
> [main] DEBUG org.apache.hc.client5.http.wire - http-outgoing-0 >> "Content-Type: application/octet-stream[\r][\n]"
> [main] DEBUG org.apache.hc.client5.http.wire - http-outgoing-0 >> "Host: localhost:8080[\r][\n]"
> [main] DEBUG org.apache.hc.client5.http.wire - http-outgoing-0 >> "Connection: keep-alive[\r][\n]"
> [main] DEBUG org.apache.hc.client5.http.wire - http-outgoing-0 >> "User-Agent: Apache-HttpClient/5.0-beta7-SNAPSHOT (Java/1.7.0_252)[\r][\n]"
> [main] DEBUG org.apache.hc.client5.http.wire - http-outgoing-0 >> "Expect: 100-continue[\r][\n]"
> [main] DEBUG org.apache.hc.client5.http.wire - http-outgoing-0 >> "[\r][\n]"
> [main] DEBUG org.apache.hc.client5.http.wire - http-outgoing-0 << "HTTP/1.1 307 [\r][\n]"
> [main] DEBUG org.apache.hc.client5.http.wire - http-outgoing-0 << "Location: /bb/redirected/repo/my.file[\r][\n]"
> [main] DEBUG org.apache.hc.client5.http.wire - http-outgoing-0 << "Content-Length: 0[\r][\n]"
> [main] DEBUG org.apache.hc.client5.http.wire - http-outgoing-0 << "Date: Mon, 17 Feb 2020 20:22:32 GMT[\r][\n]"
> [main] DEBUG org.apache.hc.client5.http.wire - http-outgoing-0 << "Connection: close[\r][\n]"
> [main] DEBUG org.apache.hc.client5.http.wire - http-outgoing-0 << "[\r][\n]"
> [main] DEBUG org.apache.hc.client5.http.headers - http-outgoing-0 << HTTP/1.1 307
> [main] DEBUG org.apache.hc.client5.http.headers - http-outgoing-0 << Location: /bb/redirected/repo/my.file
> [main] DEBUG org.apache.hc.client5.http.headers - http-outgoing-0 << Content-Length: 0
> [main] DEBUG org.apache.hc.client5.http.headers - http-outgoing-0 << Date: Mon, 17 Feb 2020 20:22:32 GMT
> [main] DEBUG org.apache.hc.client5.http.headers - http-outgoing-0 << Connection: close
> [main] DEBUG org.apache.hc.client5.http.wire - http-outgoing-0 >> "I am a checksum"
> [main] DEBUG org.apache.hc.client5.http.impl.io.DefaultManagedHttpClientConnection - http-outgoing-0: close connection IMMEDIATE
> [main] DEBUG org.apache.hc.client5.http.impl.classic.InternalHttpClient - ep-00000000: endpoint closed
> [main] DEBUG org.apache.hc.client5.http.impl.classic.InternalHttpClient - ep-00000000: discarding endpoint
> [main] DEBUG org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager - ep-00000000: releasing endpoint
> [main] DEBUG org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager - ep-00000000: connection released [route: {}->http://localhost:8080][total available: 0; route allocated: 0 of 5; total allocated: 0 of 25]
> [main] DEBUG org.apache.hc.client5.http.impl.classic.ProtocolExec - ex-00000001: Cannot retry non-repeatable request
> [main] DEBUG org.apache.hc.client5.http.impl.classic.HttpRequestRetryExec - ex-00000001: cannot retry non-repeatable request
> [main] DEBUG org.apache.hc.client5.http.impl.classic.RedirectExec - ex-00000001: cannot redirect non-repeatable request
> [main] DEBUG org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager - Shutdown connection pool GRACEFUL
> [main] DEBUG org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager - Connection pool shut down
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
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Possible bug in RedirectExec in HttpClient 5.0-beta7
Posted by Oleg Kalnichevski <ol...@apache.org>.
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-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Possible bug in RedirectExec in HttpClient 5.0-beta7
Posted by Michael Osipov <mi...@apache.org>.
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-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Possible bug in RedirectExec in HttpClient 5.0-beta7
Posted by Oleg Kalnichevski <ol...@apache.org>.
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-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Possible bug in RedirectExec in HttpClient 5.0-beta7
Posted by Michael Osipov <mi...@apache.org>.
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-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Possible bug in RedirectExec in HttpClient 5.0-beta7
Posted by Oleg Kalnichevski <ol...@apache.org>.
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-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Possible bug in RedirectExec in HttpClient 5.0-beta7
Posted by Michael Osipov <mi...@apache.org>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Possible bug in RedirectExec in HttpClient 5.0-beta7
Posted by Oleg Kalnichevski <ol...@apache.org>.
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.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org