[
https://issues.apache.org/jira/browse/HTTPCORE-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16803838#comment-16803838
]
ASF subversion and git services commented on HTTPCORE-573:
----------------------------------------------------------
Commit e0991d9bcc727ada0ccb2c282c11fdea9063c53f in httpcomponents-core's branch
refs/heads/4.4.x from Oleg Kalnichevski
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=e0991d9 ]
Merge pull request #114 from suiryc/HTTPCORE-573
HTTPCORE-573
> FileContentDecoder don't always enforce the maximum number of bytes to
> transfer
> -------------------------------------------------------------------------------
>
> Key: HTTPCORE-573
> URL: https://issues.apache.org/jira/browse/HTTPCORE-573
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore NIO
> Affects Versions: 4.4.11
> Reporter: Julien Coloos
> Priority: Trivial
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The FileContentDecoder.transfer function has the 'count' parameter indicating
> the maximum number of bytes to transfer.
> Implementations (LengthDelimitedDecoder and IdentityDecoder) don't respect
> this parameter when getting the data from the internal buffer: in practice
> the whole buffer content is transferred, thus the actual number of bytes
> transferred may exceed the maximum requested by caller.
> Since the way data are read from the buffer can be limited, it is possible to
> respect the requested 'count'.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
