[
https://issues.apache.org/jira/browse/HTTPCORE-781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17936787#comment-17936787
]
Julio J. Gomez Diaz commented on HTTPCORE-781:
----------------------------------------------
[~olegk] Please read: [https://www.rfc-editor.org/rfc/rfc9112.html#section-6.1]
, I quote:
[...]
A recipient MUST be able to parse the chunked transfer coding ([Section
7.1|https://www.rfc-editor.org/rfc/rfc9112.html#chunked.encoding]) because it
plays a crucial role in framing messages when the content size is not known in
advance. A sender MUST NOT apply the chunked transfer coding more than once to
a message body (i.e., chunking an already chunked message is not allowed). If
any transfer coding other than chunked is applied to a request's content, the
sender MUST apply chunked as the final transfer coding to ensure that the
message is properly framed. If any transfer coding other than chunked is
applied to a response's content, the sender MUST either apply chunked as the
final transfer coding or terminate the message by closing the connection. For
example,
Transfer-Encoding: gzip, chunked
indicates that the content has been compressed using the gzip coding and then
chunked using the chunked coding while forming the message body.
[...]
As you can see, the example provided by the RFC is expected to be considered as
valid.
This page ( [https://hc.apache.org/httpcomponents-client-5.4.x/index.html] )
about HttpClient 5 highlights:
h2. Standards Compliance
HttpClient strives to conform to the following specifications endorsed by the
Internet Engineering Task Force (IETF) and the internet at large:
* [RFC 9110|https://datatracker.ietf.org/doc/html/rfc9110] - HTTP Semantics
* [RFC 9111|https://datatracker.ietf.org/doc/html/rfc9111] - HTTP Caching
* [RFC 9112|https://datatracker.ietf.org/doc/html/rfc9112] - Hypertext
Transfer Protocol Version 1.1 (HTTP/1.1)
* [RFC 7540|https://datatracker.ietf.org/doc/html/rfc7540] - Hypertext
Transfer Protocol Version 2 (HTTP/2)
* [RFC 7541|https://datatracker.ietf.org/doc/html/rfc7541] - HPACK: Header
Compression for HTTP/2
* [RFC 1945|https://datatracker.ietf.org/doc/html/rfc1945] - Hypertext
Transfer Protocol – HTTP/1.0
* [RFC 2396|https://datatracker.ietf.org/doc/html/rfc2396] - Uniform Resource
Identifiers (URI): Generic Syntax
* [RFC 6265|https://datatracker.ietf.org/doc/html/rfc6265] - HTTP State
Management Mechanism (Cookies)
* [RFC 7616|https://datatracker.ietf.org/doc/html/rfc7616] - HTTP Digest
Access Authentication
* [RFC 7617|https://datatracker.ietf.org/doc/html/rfc7617] - HTTP ‘Basic’
Authentication Scheme
* [RFC 5861|https://datatracker.ietf.org/doc/html/rfc5861] - HTTP
Cache-Control Extensions for Stale Content
So I guess standards (RFC) compliance is a design principle. If it is, you
shouldn't _choose_ which section to enforce and which to ignore. IMHO all the
sections should be respected.
If that's not the case I think this statements about "standards compliance"
should be modified and clarified at the main page:
[https://hc.apache.org/httpcomponents-client-5.4.x/index.html]
*At the end of the day I am only looking for documented clarification of this
topic. Avoiding having the explanation in difficult to find internal
conversation but exposing it in the public documentation.*
Best regards, and thanks for your time.
cC: [~abernal]
> DefaultContentLengthStrategy does not conform to RFC 9112 regarding
> Transfer-encoding HTTP header
> -------------------------------------------------------------------------------------------------
>
> Key: HTTPCORE-781
> URL: https://issues.apache.org/jira/browse/HTTPCORE-781
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore
> Affects Versions: 5.3.3
> Reporter: Julio J. Gomez Diaz
> Priority: Major
>
> I noticed that changes for 5.3.x in class
> "org.apache.hc.core5.http.impl.DefaultContentLengthStrategy" (this commit:
> [https://github.com/apache/httpcomponents-core/commit/7fea9ef7fa2be53a7631aad9bb484db7347667be#diff-385ee34bb5e36b01eb7c355de9557d7f830ba5a202f156057ac3559507ea5c7aR44-R68]
> ) are not compliant to what is described in RFC 9112 section 6.1 (
> [https://www.rfc-editor.org/rfc/rfc9112.html#section-6.1] ) at least in this
> example, presented in the RFC section as a VALID example:
> {code:java}
> Transfer-Encoding: gzip, chunked{code}
> With 5.3.x it fails throwing an exception via this line:
> {code:java}
> throw new NotImplementedException("Unsupported transfer encoding: " +
> teh.getValue());{code}
> effectively printing in the stack trace:
> "Unsupported transfer encoding: gzip,chunked"
>
>
>
>
--
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
