From: Dean Hiller <dean_at_xsoftware.biz>
Date: Wed, 12 Dec 2012 11:02:03 -0700

thanks much for the help!!!! I will have to take a look at that.


On Wed, Dec 12, 2012 at 9:24 AM, Oleksiy Stashok <oleksiy.stashok_at_oracle.com
> wrote:

>
> On 12/12/2012 05:01 PM, Ryan Lubke wrote:
>
> The core http module classes are here [1]. In particular, you'll want to
> review HttpCodecFilter, HttpServerFilter, and possibly HttpClientFilter.
>
> However, this module does rely on the core framework for Buffer (Grizzly
> specific Buffer implementation) management, and FilterChain.
>
> Agree w/ Ryan.
> In general IMO it shouldn't be difficult to wrap Grizzly HttpServerFilter
> with some Parser API.
>
> It may look like:
> *
> **private HttpPacket parse(byte[] bytes) {**
> ** Buffer inBuffer = Buffers.wrap(**MemoryManager.DEFAULT_MEMORY_MANAGER,
> **bytes);**
> ** FilterChainContext dummyContext = createDummyContext(bytes);**
> ** **NextAction nextAction = httpServerFilter.handleRead(dummyContext);
> **
> **
> ** if (nextAction.type() == 0) { // InvokeAction**
> ** return dummyContext.getMessage();**
> ** }**
> **
> ** return null;**
> **}*
>
> For sure in case you have more than 1 ready HTTP packets in byte[] it
> won't be enough... you will also need to check nextAction's remainder.
> We can accept any reasonable refactoring, which will help you.
>
> WBR,
> Alexey.
>
>
>
>
>
> [1]
> http://java.net/projects/grizzly/sources/git/show/modules/http/src/main/java/org/glassfish/grizzly/http?rev=7cead2409f03397650391bc4f0d1d3c797cedb81
>
> Dean Hiller <dean_at_xsoftware.biz>
> December 12, 2012 5:17 AM
> Because we are doing some research and something pretty complex with
> tcp flow control and all we need is the parser to accomplish this. We
> looked at both netty and grizzly and would have to make major
> modifications. Most people writing parsers write a re-usable one, but we
> looked at netty's and their parser is tightly coupled with netty itself.
> We are hoping grizzly might have a few classes for parsing that are used
> that are not so tightly coupled??? Maybe you could point me to the classes
> used for parsing?
>
> thanks,
> Dean
>
>
> Ryan Lubke <ryan.lubke_at_oracle.com>
> December 11, 2012 3:49 PM
> The Grizzly HTTP framework already does this - why not use it? Can you
> go into details on what you're trying to accomplish? Also, what version of
> Grizzly are you currently using?
>
>
>
> dean_at_xsoftware.biz
> December 11, 2012 3:32 PM
> Is there re-usable code in grizzly that I can use for http parsing?
> ie. It would be great to feed in bytes like so and it returns null if
> there is not yet enough bytes
>
> private byte[] previousData;
>
> byte[] data = incomingMergedWithPrevious(previousData);
> HttpResponse resp = httpResponseParser.parse(data);
> if(resp == null) {
> return; //we do not have full data to parse yet
> }
>
> //otherwise fire the response to someone else.
>
> OR maybe I could re-use the code a different way. All I know is I get
> bytes that don't always have all the http headers yet since it is
> asynch stuff. Any way to parse stuff?
>
> thanks,
> Dean
>
>
>