caa1505020
Proposal to fix issue #3636 Motivations: Currently, while adding the next buffers to the decoder (`decoder.offer()`), there is no way to access to the current HTTP object being decoded since it can only be available currently once fully decoded by `decoder.hasNext()`. Some could want to know the progression on the overall transfer but also per HTTP object. While overall progression could be done using (if available) the global Content-Length of the request and taking into account each HttpContent size, the per HttpData object progression is unknown. Modifications: 1) For HTTP object, `AbstractHttpData` has 2 protected properties named `definedSize` and `size`, respectively the supposely final size and the current (decoded until now) size. This provides a new method `definedSize()` to get the current value for `definedSize`. The `size` attribute is reachable by the `length()` method. Note however there are 2 different ways that currently managed the `definedSize`: a) `Attribute`: it is reset each time the value is less than actual (when a buffer is added, the value is increased) since the final length is not known (no Content-Length) b) `FileUpload`: it is set at startup from the lengh provided So these differences could lead in wrong perception; a) `Attribute`: definedSize = size always b) `FileUpload`: definedSize >= size always Therefore the comment tries to explain clearly the different behaviors. 2) In the InterfaceHttpPostRequestDecoder (and the derived classes), I add a new method: `decoder.currentPartialHttpData()` which will return a `InterfaceHttpData` (if any) as the current `Attribute` or `FileUpload` (the 2 generic types), which will allow then the programmer to check according to the real type (instance of) the 2 methods `definedSize()` and `length()`. This method check if currentFileUpload or currentAttribute are null and returns the one (only one could be not null) that is not null. Note that if this method returns null, it might mean 2 situations: a) the last `HttpData` (whatever attribute or file upload) is already finished and therefore accessible through `next()` b) there is not yet any `HttpData` in decoding (body not yet parsed for instance) Result: The developper has more access and therefore control on the current upload. The coding from developper side could looks like in the example in HttpUloadServerHandler. |
||
|---|---|---|
| all | ||
| buffer | ||
| codec | ||
| codec-dns | ||
| codec-haproxy | ||
| codec-http | ||
| codec-http2 | ||
| codec-memcache | ||
| codec-mqtt | ||
| codec-socks | ||
| codec-stomp | ||
| codec-xml | ||
| common | ||
| example | ||
| handler | ||
| handler-proxy | ||
| license | ||
| microbench | ||
| resolver | ||
| resolver-dns | ||
| tarball | ||
| testsuite | ||
| testsuite-osgi | ||
| transport | ||
| transport-native-epoll | ||
| transport-rxtx | ||
| transport-sctp | ||
| transport-udt | ||
| .fbprefs | ||
| .gitignore | ||
| .travis.yml | ||
| CONTRIBUTING.md | ||
| LICENSE.txt | ||
| NOTICE.txt | ||
| pom.xml | ||
| README.md | ||
| run-example.sh | ||
Netty Project
Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients.
Links
How to build
For the detailed information about building and developing Netty, please visit the developer guide. This page only gives very basic information.
You require the following to build Netty:
- Latest stable Oracle JDK 7
- Latest stable Apache Maven
- If you are on Linux, you need additional development packages installed on your system, because you'll build the native transport.
Note that this is build-time requirement. JDK 5 (for 3.x) or 6 (for 4.0+) is enough to run your Netty-based application.
Branches to look
The 'master' branch is where the development of the latest major version lives on. The development of all other versions takes place in each branch whose name is identical to <majorVersion>.<minorVersion>. For example, the development of 3.9 and 4.0 resides in the branch '3.9' and the branch '4.0' respectively.