[
https://issues.apache.org/jira/browse/HTTPCORE-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16182701#comment-16182701
]
ASF subversion and git services commented on HTTPCORE-491:
----------------------------------------------------------
Commit 47411d22b3150010ac794a166b7c284be22b82cf in httpcomponents-core's branch
refs/heads/4.4.x from [~mheemskerk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=47411d2 ]
HTTPCORE-491 Make BasicAsyncRequest|ResponseConsumer more paranoid
BasicAsyncRequestConsumer and BasicAsyncResponseConsumer used to
blindly pre-allocate a buffer of Content-Length. If the request / response
is crafted to have a very large Content-Length header, this can result in
OutOfMemoryErrors.
This limits the initial buffer size to 256kb, while still allowing the
buffer to grow if a larger message is read.
> BasicAsyncResponseConsumer can easily be tricked into triggering an OOME
> ------------------------------------------------------------------------
>
> Key: HTTPCORE-491
> URL: https://issues.apache.org/jira/browse/HTTPCORE-491
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore NIO
> Affects Versions: 4.4.7
> Reporter: Michael Heemskerk
> Fix For: 4.4.8
>
>
> When using {{BasicAsyncResponseConsumer}} to consume a response, the consumer
> initializes its {{SimpleInputBuffer}} with the value reported on the
> response's {{Content-Length}} header.
> It's easy to spoof a response with a very large (but smaller than
> Integer.MAX_VALUE) {{Content-Length}} header and have the client pre-allocate
> a massive buffer, triggering an OOME.
> Since {{SimpleInputBuffer}} already expands-on-demand, it would be trivial to
> cap the initial buffer size to some reasonable limit (256k or even 1M)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
