You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Roland Weber (JIRA)" <ji...@apache.org> on 2007/09/08 17:26:29 UTC

[jira] Created: (HTTPCORE-115) StrictContentLengthStrategy misinterprets Transfer-Encoding header

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


[jira] Resolved: (HTTPCORE-115) StrictContentLengthStrategy misinterprets Transfer-Encoding header

Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/HTTPCORE-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Oleg Kalnichevski resolved HTTPCORE-115.
----------------------------------------

    Resolution: Won't Fix

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


[jira] Issue Comment Edited: (HTTPCORE-115) StrictContentLengthStrategy misinterprets Transfer-Encoding header

Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
    [ 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