You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Oleg Kalnichevski (JIRA)" <ji...@apache.org> on 2007/09/08 18:50:29 UTC
[jira] Issue Comment Edited: (HTTPCORE-115)
StrictContentLengthStrategy misinterprets Transfer-Encoding header
[ 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: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org