[
https://issues.apache.org/jira/browse/HTTPCORE-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525929
]
olegk edited comment on HTTPCORE-115 at 9/8/07 9:50 AM:
--------------------------------------------------------------------
Roland
This is intentional. Even though RFC 2616 allows for multiple transfer codings,
'chunked' is the only value used practice. I have never seen even 'identity'
coding. I am not in favor of adding a more complex processing without any
practical benefit.
Oleg
was (Author: olegk):
Roland
This is intentional. Even though RFC 2616 allows for multiple transfer codings,
'chunked' is the only value used practice. I have never seen even 'identity'
coding. I am not in favor in adding a more complex processing without any
practical benefit.
Oleg
> StrictContentLengthStrategy misinterprets Transfer-Encoding header
> ------------------------------------------------------------------
>
> Key: HTTPCORE-115
> URL: https://issues.apache.org/jira/browse/HTTPCORE-115
> Project: HttpComponents Core
> Issue Type: Bug
> Components: HttpCore
> Affects Versions: 4.0-alpha5
> Reporter: Roland Weber
> Priority: Trivial
>
> StrictContentLengthStrategy assumes that the Transfer-Encoding header is
> single-valued, while RFC 2616 specifies it is a list.
> I've seen a few of these misinterpretations lately, and there probably are
> more. Maybe we should have a convenient way to iterate over header values,
> and/or to check for the presence of a specific value. Otherwise we'll have to
> spread code for iterating over headers with the same name and for splitting
> the header values into elements all over the place.
> cheers,
> Roland
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
