Shipping an official HTTP client in Netty (NETTY-333)

[Kevin Burton]

I thought about this but there are a number of issues regarding HTTP that
need to be addressed:

- infinite DNS caching
- TCP connect timeout/ read timeout
- User-Agent headers
- redirect handling
- gzip encoding
- I could go on...

... doing this 2 different ways for 2 different implementations is no fun
and will lead to bugs.

On Thu, Oct 27, 2011 at 11:20 AM, Norman Maurer <
norman.maurer at googlemail.com> wrote:

> I think its a good think for netty to just be an api.. This helps to
> concentrate on the "core" and does not push to much dependencies etc
> in.
>
> Bye,
> Norman
>
>
> 2011/10/27 Kevin Burton <burtonator at gmail.com>:
> > I was looking at NETTY-333 (and have been thinking about this a bit
> lately)
> >
> >
> https://issues.jboss.org/browse/NETTY-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel#issue-tabs
> >
> > ... and I think Netty should ship an official HTTP client. Not just an
> > example.
> >
> > This would be a replacement for java.net.URL or say Jakarta HttpClient.
> >
> > This would have the following advantages:
> >
> > 1. More people would be able to use Netty.  Right now Netty is mostly an
> API
> > for building clients and servers but this would mean that people can use
> > Netty out of the box for their usages.
> >
> > 2. The client would use best practices and avoid common bugs.  I built a
> > client in Peregrine that uses Netty and I've already been bitten by a few
> > issues I didn't anticipate.
> >
> > 3. Developers would benefit from bugs fixed in the client moving forward
> as
> > they are fixed.
> >
> > I also think we may need to build a different type of client that isn't
> > necessarily fully async.
> >
> > What I did with peregrine (as it fits directly into the model I need) is
> > that we write to a buffer from the main thread.  The buffer then writes
> to
> > Netty which then does Async IO (this is an HTTP PUT client).  The great
> > thing about this model is that if the receiver can't handle the data
> being
> > sent to it, the client just blocks.
> >
> > In our usage we often write from 1 client to N servers.  Anywhere from
> > 10-1000 ... so the async buys us the ability to not need 1k threads doing
> > the IO.
> >
> > Thoughts?
> >
> > _______________________________________________
> > netty-users mailing list
> > netty-users at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/netty-users
> >
>
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/netty-users/attachments/20111027/22101ceb/attachment.html