Feel free to take a stab at the HTTP decoding. Currently we have two open issues targeting http decoding: https://issues.apache.org/jira/browse/DEFT-144 (Improved HTTP headers parsing) and https://issues.apache.org/jira/browse/DEFT-120 (HTTP Post decoding) If your work is not covered by those feel free to create a new issue.
About the body: I like the simple design where the application developer will fetch the entire http post/put body with a simple call like request.getBody() :: String. ...On the other hand I can see the drawbacks (memory consumption) of this approach. "..the body should be passed through to the application as fast as we received it" Do you propose that we should have a callback, like onChunk(String/byte[] nextChunk), that the application developer will have to take care of...and we deliver chunk after chunk as fast as we can receiver new ones? // Roger On Fri, Jul 22, 2011 at 11:09 AM, Emmanuel Lecharny <[email protected]>wrote: > On 7/22/11 11:06 AM, Roger Schildmeijer wrote: > >> Hi, >> >> First of all...I think that some parts of the (naive) http decoding in >> Deft >> should probably be improved and/or refactored... >> Currently the http chunks are concatenated and accumulated (as a >> java.lang.String) in an PartialHttpRequest instance. >> >> The interesting code path for this is. >> HttpProtocol.handleRead -> >> HttpProtocol.getHttpRequest -> >> HttpProtocol.doGetHttpRequest -> >> >> HttpRequest.of (1st chunk) -> >> HttpRequest.continueParsing (2nd, 3rd, .. etc, chunk) -> >> >> Let me know if this makes sense... >> > > I can give you a hand on the HTTP decoder. It's very unlikely that the HTTP > header will become big. The body is another story. IMO, once the header has > been decoded, the body should be passed through to the application as fast > as we received it. It will then be up to the application to manage bug > pages. > > Does it make sense ? > > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com > >
