[
https://issues.apache.org/jira/browse/HTTPCLIENT-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884355#comment-17884355
]
Oleg Kalnichevski commented on HTTPCLIENT-2344:
-----------------------------------------------
> Servers are not obliged to follow RFC-2817. It is not part of the HTTP/1.1
> spec.
[~bplotnick] There is not a word in RFRC 9110 about it making RFC 2817 obsolete.
> This also does not prescribe server behavior and I don't believe a server
> would be out of spec to reject this request.
You are making things up. There is not a word about about servers rejecting
such requests, only that it is legal to ignore it.
> Breaking clients by default is backwards incompatible and unacceptable
Really? Breaking? I am very tempted to close this ticker as INVALID right here
and now. However it will wait for the wire log with the session and will retest
our code with Squid 3 to make sure we have not missed or overlooked something.
Oleg
> HTTP/1.1 TLS Upgrade (RFC-2817) should not be default
> -----------------------------------------------------
>
> Key: HTTPCLIENT-2344
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2344
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
> Affects Versions: 5.4
> Reporter: Ben Plotnick
> Priority: Minor
> Fix For: 5.4.1
>
>
> Version 5.4 added RFC-2817 support, which by default tries to upgrade since
> protocolUpgradeEnabled is default enabled.
> Although the strict reading of the spec would indicate that a server should
> ignore upgrade requests that it cannot service, conservative proxies might
> reject these requests entirely. This is the case in Envoy today
> I don't see a big advantage to enabling this by default and it is causing
> real issues now.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
