[
https://issues.apache.org/jira/browse/HTTPCLIENT-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18031124#comment-18031124
]
Nathan Bryant edited comment on HTTPCLIENT-1482 at 10/20/25 11:51 AM:
----------------------------------------------------------------------
[~olegk] "because it can't" is quite a bold–and {_}incorrect{_}–statement.
`Expect: 100-continue` is a defined part of the protocol, and conforming
servers will support it, so "abuse" is in the eye of the beholder here.
This was requested at a time when I was dealing with 3rd party servers (outside
of my control) that had issues with reachability and responsiveness. So to some
extent this would be a debugging feature, to be turned on only when necessary
(it obviously adds a round-trip), but the thinking when I requested this was
that for a connection that has been cached for some time, it can be useful to
confirm reachability, before sending a non-idempotent request, to reduce the
probability of getting into a situation where you don't know whether a server
received and acted on a request that can't necessarily be retried cleanly.
was (Author: nbryant):
[~olegk] "because it can't" is quite a bold–and \{_}incorrect{_}–statement.
`Expect: continue` is a defined part of the protocol, and conforming servers
will support it, so "abuse" is in the eye of the beholder here.
This was requested at a time when I was dealing with 3rd party servers (outside
of my control) that had issues with reachability and responsiveness. So to some
extent this would be a debugging feature, to be turned on only when necessary
(it obviously adds a round-trip), but the thinking when I requested this was
that for a connection that has been cached for some time, it can be useful to
confirm reachability, before sending a non-idempotent request, to reduce the
probability of getting into a situation where you don't know whether a server
received and acted on a request that can't necessarily be retried cleanly.
> ability to expect-continue only if potentially stale
> ----------------------------------------------------
>
> Key: HTTPCLIENT-1482
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1482
> Project: HttpComponents HttpClient
> Issue Type: Wish
> Components: HttpClient (classic)
> Reporter: Nathan Bryant
> Priority: Minor
> Fix For: 5.6-alpha1
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> If the stale check fails, non-idempotent queries such as POST can return a
> "no response from server" error to the application stack, resulting in
> ambiguity as to whether the request was received and acted on in some fashion
> by the host, possibly resulting in a server-side error.
> Might be nice as a RequestConfig option to be able to enable the
> expect-continue handshake only for cases where the connection was recycled
> from a pool.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
