[erlang-questions] HTTP clients

[Tristan Sloughter]

Now to http clients instead of servers :)

Over the years I've bounced between httpc, lhttpc and ibrowse (I think that's all...) and was wondering what opinions people had on the 3 and which are still developed and used in production.

It seems ibrowse has the most features and most development going on.

Though examples are lacking for all of them... So on a side note if anyone has an example of posting form data with ibrowse that would be much appreciated.

Thanks,

Tristan

[Max Lapshin]

I've rxperienced extremely high load with ibrowse: about 60% for downloading one file.

I had to add my own implementation to erlyvideo

[Tristan Sloughter]

So you modified it here, https://github.com/erlyvideo/erlyvideo/tree/master/apps/ibrowse ?

Is there a reason these changes aren't added to the main ibrowse repo?

[Max Lapshin]

On Sat, Feb 18, 2012 at 9:06 PM, Tristan Sloughter
<tristan....@gmail.com> wrote:
> So you modified it here,
> https://github.com/erlyvideo/erlyvideo/tree/master/apps/ibrowse ?
>
> Is there a reason these changes aren't added to the main ibrowse repo?
>

No, I speak about
https://github.com/erlyvideo/erlyvideo/blob/master/apps/erlmedia/src/http_stream.erl

this piece of code is a very, very limited subset of ibrowse. But it
solves one very important for me problem: deliver large amount of
video data in thousands of simultaneous streams.
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

[Rapsey]

We used ibrowse for a while as well. We didn't have the high CPU bug, but we did have a lot of failed requests for which there was no reason for them to fail. The keepalive connection pooling seems to have some bugs. We also just went and implemented a really simple http library, that always creates a new tcp connection and closes when it's done.

Sergej

[Garrett Smith]

If I just need to grab a file, I'll call out to curl :)

It'd be nice to have a solid httpc module in the core. It *seems* that
httpc is close, but every now and then you'll spot some odd, hard to
reproduce buggy behavior. For me that was a while ago -- it may have
seen some improvements lately.

Garrett

[Zabrane Mickael]

On Feb 18, 2012, at 9:26 PM, Garrett Smith wrote:

On Sat, Feb 18, 2012 at 9:30 AM, Tristan Sloughter
<tristan....@gmail.com> wrote:

Now to http clients instead of servers :)

Over the years I've bounced between httpc, lhttpc and ibrowse (I think

that's all...) and was wondering what opinions people had on the 3 and which

are still developed and used in production.

It seems ibrowse has the most features and most development going on.

Though examples are lacking for all of them... So on a side note if anyone

has an example of posting form data with ibrowse that would be much

appreciated.

If I just need to grab a file, I'll call out to curl :)

May be semonce car start from here to make this linked-in driver stable:

http://www.chrisumbel.com/article/c_from_erlang_curl

Regards,

Zabrane

[Tim Watson]

httpc is perfectly fine for most applications - Max had a slightly
more demanding use case than is usual for a generic http client and
clearly it made sense for him to do something specific in that area.

I've used ibrowse in situations where I'm stuck behind a corporate
proxy and inets won't upgrade the socket to ssl, making it impossible
to access https urls. This was mentioned on the list and I'm pretty
sure it's on the 'TODO' list for the otp team to fix. Apart from that,
httpc has never let me down and the scenarios where I'm using ibrowse
are very lightweight, so I can't comment on its utility very broadly.

[Chandru]

On 18 February 2012 19:56, Rapsey <rap...@gmail.com> wrote:

We used ibrowse for a while as well. We didn't have the high CPU bug, but we did have a lot of failed requests for which there was no reason for them to fail. The keepalive connection pooling seems to have some bugs. We also just went and implemented a really simple http library, that always creates a new tcp connection and closes when it's done.

The load balancing and pipelining feature had a bit of a rewrite in the run up to the 3.0 version, so should be fixed now.

cheers
Chandru