On Wed, May 11, 2011 at 11:21 AM, Scott Lamb wrote:
> On Wed, May 11, 2011 at 10:12 AM, Cliff Frey wrote:
>> I spent some more time thinking about this, and I have a few use cases that
>> it might be worth keeping in mind.
>>
>> It would be nice if the API made it easy to hook up a received HTTP
On Wed, May 11, 2011 at 10:12 AM, Cliff Frey wrote:
> I spent some more time thinking about this, and I have a few use cases that
> it might be worth keeping in mind.
>
> It would be nice if the API made it easy to hook up a received HTTP request
> (where we are the server) to an outgoing HTTP req
I spent some more time thinking about this, and I have a few use cases that
it might be worth keeping in mind.
It would be nice if the API made it easy to hook up a received HTTP request
(where we are the server) to an outgoing HTTP request (where we are the
client) in order to make building an HT
On Wed, May 11, 2011 at 04:20:33AM -0700, Scott Lamb wrote:
> It's libevent's doom, too: the extra code for spooling is a
> maintenance burden. I don't like options C or D.
>
I am officially out of this thread. This back and forth has obviously
derailed with reasons-why-not instead of how-about-w
On Tue, May 10, 2011 at 9:11 PM, Mark Ellzey wrote:
> On Tue, May 10, 2011 at 04:04:27PM -0700, Scott Lamb wrote:
>> I don't see the point in libevent implementing spooling to a file
>> (descriptor). If an application wants that, it can implement it on top
>> of the existing evhttp_request_set_chu
>
> So I like the idea of getting read-by-read notification of data as it
> arrives. I'm not thrilled with the idea of changing default behavior
> wrt what counts as a read, though. Either a flag or another kind of
> callback would make me much more comfortable about the change here.
I will try
I just whipped up a quick bare-bones http server using only bufferevents
and a MIT licensed http parser (which if I am not mistaken - is
compatible with bsd).
https://github.com/ellzey/bufferevent_http_parser/blob/master/evhttp.c
This is the type of control I would look for in a http request pro
On Tue, May 10, 2011 at 04:04:27PM -0700, Scott Lamb wrote:
> I don't see the point in libevent implementing spooling to a file
> (descriptor). If an application wants that, it can implement it on top
> of the existing evhttp_request_set_chunked_cb + the fairly small
> patches being proposed (call
On Tue, May 10, 2011 at 04:14:42PM -0700, Scott Lamb wrote:
> It occurs to me by "install a handler for" you might be meaning a
> custom filesystem via kernel module or FUSE or something. I don't like
> that either;
I never said nor implied such a thing.
**
On Tue, May 10, 2011 at 4:04 PM, Scott Lamb wrote:
> On Tue, May 10, 2011 at 4:46 AM, Mark Ellzey wrote:
>> On Tue, May 10, 2011 at 09:04:42AM +0200, Roman Puls wrote:
>>> whilst this might be nice for flow-blown web services, this does not
>>> work for embedded systems that have no or very limit
On Tue, May 10, 2011 at 4:46 AM, Mark Ellzey wrote:
> On Tue, May 10, 2011 at 09:04:42AM +0200, Roman Puls wrote:
>> whilst this might be nice for flow-blown web services, this does not
>> work for embedded systems that have no or very limited disk storage.
>>
>> Also, this pattern disables effect
On Tue, May 10, 2011 at 09:04:42AM +0200, Roman Puls wrote:
> whilst this might be nice for flow-blown web services, this does not
> work for embedded systems that have no or very limited disk storage.
>
> Also, this pattern disables effective stream handling, e.g. where
> you don't want to store
On May 07.05.2011 20:26, Mark Ellzey wrote:
On Sat, May 07, 2011 at 01:07:40AM -0400, Nick Mathewson wrote:
*lots of text here*
One of the ways nginx deals with very large streams of data is to
actually spool the data to file. By default this is turned off. But
this may be a simple solution to
I think it may this may be a good time for Cliff, Vector, Scott,
myself, and input/time from Nick to give a shot creating a
secondary http API (keeping the old one in place).
This thread has been full of good ideas and experimental
implementations. A call to arms?
***
On Sat, May 07, 2011 at 01:07:40AM -0400, Nick Mathewson wrote:
> *lots of text here*
One of the ways nginx deals with very large streams of data is to
actually spool the data to file. By default this is turned off. But
this may be a simple solution to all of these problems.
The spooling is tra
On Fri, May 6, 2011 at 10:07 PM, Nick Mathewson wrote:
> On Sat, Apr 30, 2011 at 9:55 PM, Cliff Frey wrote:
>> I added tests, handled the infinite-receive case as well as the
>> infinite-send case, and slightly renamed a few things.
>>
>> https://github.com/clifffrey/Libevent/tree/http-transfer-t
On Sat, Apr 30, 2011 at 9:55 PM, Cliff Frey wrote:
> I added tests, handled the infinite-receive case as well as the
> infinite-send case, and slightly renamed a few things.
>
> https://github.com/clifffrey/Libevent/tree/http-transfer-throttling
>
> I believe that the changes there are enough to p
>> https://github.com/clifffrey/Libevent/tree/http-transfer-throttling
>>
>> I believe that the changes there are enough to prevent out-of-memory
>> conditions when sending or receiving huge HTTP requests.
>
> Great; I will try to review and either merge or comment some time this
> week. Please bu
On Sat, Apr 30, 2011 at 9:55 PM, Cliff Frey wrote:
> I added tests, handled the infinite-receive case as well as the
> infinite-send case, and slightly renamed a few things.
>
> https://github.com/clifffrey/Libevent/tree/http-transfer-throttling
>
> I believe that the changes there are enough to p
I added tests, handled the infinite-receive case as well as the
infinite-send case, and slightly renamed a few things.
https://github.com/clifffrey/Libevent/tree/http-transfer-throttling
I believe that the changes there are enough to prevent out-of-memory
conditions when sending or receiving huge
On Tue, Apr 26, 2011 at 5:26 PM, Mark Ellzey wrote:
[...]
> While I support these types of changes, I often wonder if the better
> solution to these problems is to gut the httpd API and create a more robust
> and abstracted replacement. *prepares for flogging*
>
> Libevent's http API was created
On Tue, Apr 26, 2011 at 1:49 PM, Cliff Frey wrote:
> (apologies if this is a duplicate post)
>
> It might be clearer to just look at my patches and commit messages
> https://github.com/clifffrey/Libevent/commits/http_oom_prevention
> But I've summarized my problems/fixes below. Please let me k
> While I support these types of changes, I often wonder if the better
> solution to these problems is to gut the httpd API and create a more robust
> and abstracted replacement. *prepares for flogging*
>
> Libevent's http API was created for JIT services, not a apache/nginx/iis
> replacement. But
On Tue, Apr 26, 2011 at 10:49:46AM -0700, Cliff Frey wrote:
> Also, a completely different bug: ?If you want to support potentially
> infinite POST streams from clients (imagine that you wanted to
> implement word-count as an http server, where they POST a document,
> and you return the word count)
2011/4/26 Cliff Frey :
> To do this, I need to be able to get a callback when
> evhttp_connection->bufev's write buffer is empty (or close to empty).
> I could imagine an implementation where you can explicitly check the
> length and explicitly get a callback when the length falls below some
> thre
I second this... I hacked my local version to do this, then realized the
application was depending on each chunk being newline-terminated (ie
logically complete chunk). I suspect I'm not unique in this need, so we
may want some way for the chunked callback to return the number of
characters it used
(apologies if this is a duplicate post)
It might be clearer to just look at my patches and commit messages
https://github.com/clifffrey/Libevent/commits/http_oom_prevention
But I've summarized my problems/fixes below. Please let me know if
you would rather I submit a github pull request, or a
27 matches
Mail list logo
