[ 
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: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Reply via email to