headers
Alex Evans | 1 Aug 2008 04:17
Favicon

getting notification of an evhttp_request being freed unexpectedly

hello. I'm fairly new to libevent and especially evhttp, so I have a query whose solution may just be 'dont
use evhttp that way'... the summary is: how can I know if an evhttp_request object is 'freed' behind my
back, and avoid using it after it's dead?

I'm writing a simple single threaded libevent based http server that occasionally can't immediately
respond to an incoming http request that has been passed into a generic handler callback. instead it just
saves the evhttp_request pointer in my own list structure, and doesn't immediately call
evhttp_send_reply or equivalent. instead it falls back to the main dispatch loop and lets other events happen.
some time later another event allows me to fill in a reply to the old request, and so I call evhttp_send_reply
on the stored request pointer.
my issue is, that looking at the http.c code there are a few ways that the http_request I am storing a pointer
to, could be freed. for example, if the incoming connection to a server goes away, it deletes all the
outstanding requests. however my code won't get any notification that the connection or requests have
gone away, so I will merrily (later on) make use of the request pointer after it's been freed.
what should I do? not use this pattern? use some callback mechanism I've missed? worry less? or patch
evhttp_request_free() to call an optional callback?

any help or advice greatly appreciated. many thanks
Alex

Please consider the environment before printing this email :-)

This email and any files transmitted with it are confidential and intended solely for the use of the
individual or entity to whom they are addressed.  If you have received this email in error please notify the
sender immediately then delete this email.

Media Molecule Limited
Company Reg No 5665849
Registered in England.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Derek Gottfrid | 3 Aug 2008 16:29
Picon
Gravatar

getting post data from evhttp server

I have a very small http server written using the evhttp stuff. I want
to support POST operations but I am a bit baffled on how to retrieve
the POST data.
It looks like it is in request->output_buffer (which is a bit odd that
it is called output - correct me if I am wrong) - what happens when it
is a chunked submission - how do I read data out of the evbuffer
struct - are there utility/wrapper/accessor functions?

apologies if this has been covered before - i tried to resolve via
google but wasn't getting anyway.

d
Permalink | Reply | 1 comment |
headers
Aleksandar Lazic | 3 Aug 2008 17:13
Picon
Favicon

Re: getting post data from evhttp server

D. Derek,

On Son 03.08.2008 10:29, Derek Gottfrid wrote:
>I have a very small http server written using the evhttp stuff. I want
>to support POST operations but I am a bit baffled on how to retrieve
>the POST data.
>It looks like it is in request->output_buffer (which is a bit odd that
>it is called output - correct me if I am wrong) - what happens when it
>is a chunked submission - how do I read data out of the evbuffer
>struct - are there utility/wrapper/accessor functions?
>
>apologies if this has been covered before - i tried to resolve via
>google but wasn't getting anyway.

http://monkeymail.org/archives/libevent-users/2008-June/001320.html

Hth

Aleks
Permalink | Reply | 0 comments |
headers
Derek Gottfrid | 4 Aug 2008 06:03
Picon
Gravatar

Keep Alive and POST

I noticed an oddity and want to check and see if anybody else was
seeing the same issue.

 If I call a eventlib http server w/ GET and Keep Alive and then
follow it up with a POST on the same connection, then I see a 400 Bad
Request message returned.  If I just call the POST directly on the
first call it works fine since there is not Keep Alive in play.  How
robust is the keep alive support?  I will keep digging and can post
some sample code if it helps.  Sorry for such newbie questions.

derek
Permalink | Reply | 2 comments |
headers
Adam Chou | 6 Aug 2008 11:04

A Private Invitation from Adam Chou (adam.chou <at> gmail.com)

You have got to check out this really cool site - you'll love it!  I even got you a private invitation for Shop it
To Me:

Click below to sign up:

http://www.shopittome.com/shhsecret?code=C4RdMvpYn3w5aVLK9qMJoGdAAWKnEM59J7pKVhfxLqQgY_eq

-Adam Chou

This private invitation will expire in 72 hours.

Adam Chou (adam.chou <at> gmail.com) has sent you a private invitation for Shop It To Me. If you do not want to
receive these messages, paste the following link into your browser:
http://www.shopittome.com/blocked_email/bGliZXZlbnQtdXNlcnNAbW9ua2V5Lm9yZw__

Shop It To Me, Inc. | 2269 Chestnut Street #250 | San Francisco, CA 94123
Permalink | Reply | 0 comments |
headers
Scott Lamb | 11 Aug 2008 00:25

Re: Keep Alive and POST

Derek Gottfrid wrote:
> I noticed an oddity and want to check and see if anybody else was
> seeing the same issue.
> 
>  If I call a eventlib http server w/ GET and Keep Alive and then
> follow it up with a POST on the same connection, then I see a 400 Bad
> Request message returned.  If I just call the POST directly on the
> first call it works fine since there is not Keep Alive in play.  How
> robust is the keep alive support?  I will keep digging and can post
> some sample code if it helps.  Sorry for such newbie questions.

I think the keepalive support is reasonably good by now, at least in 
trunk head. (What version are you using?)

I haven't tested that specific case, though, and I suspect no one else 
has either. I deliberately avoid reusing connections for POST requests 
when issuing requests, and I think most web browsers do the same. This 
avoids an awkward situation where a non-idempotent requests can fail 
because the server has timed out the connection, and it's not safe to 
retry. RFC 2616 section 8.1.4 touches on this.

> 
> derek
> _______________________________________________
> Libevent-users mailing list
> Libevent-users <at> monkey.org
> http://monkeymail.org/mailman/listinfo/libevent-users
Permalink | Reply | 1 comment |
headers
Derek Gottfrid | 11 Aug 2008 03:31
Picon
Gravatar

Re: Keep Alive and POST

Yeah. The solution to my problem was just close connection on POST and
in the context of what i am doing it makes the most sense anyway -
although i think it might be the "right" thing to do in general for
all POSTs.

d

On Sun, Aug 10, 2008 at 6:25 PM, Scott Lamb <slamb <at> slamb.org> wrote:
> Derek Gottfrid wrote:
>>
>> I noticed an oddity and want to check and see if anybody else was
>> seeing the same issue.
>>
>>  If I call a eventlib http server w/ GET and Keep Alive and then
>> follow it up with a POST on the same connection, then I see a 400 Bad
>> Request message returned.  If I just call the POST directly on the
>> first call it works fine since there is not Keep Alive in play.  How
>> robust is the keep alive support?  I will keep digging and can post
>> some sample code if it helps.  Sorry for such newbie questions.
>
> I think the keepalive support is reasonably good by now, at least in trunk
> head. (What version are you using?)
>
> I haven't tested that specific case, though, and I suspect no one else has
> either. I deliberately avoid reusing connections for POST requests when
> issuing requests, and I think most web browsers do the same. This avoids an
> awkward situation where a non-idempotent requests can fail because the
> server has timed out the connection, and it's not safe to retry. RFC 2616
> section 8.1.4 touches on this.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jon Singler | 11 Aug 2008 21:47
Picon

the mystery of the forbidden Accept-Encoding header

I'm starting a new project using the HTTP bits of libevent, and so far
it's going well. The HTTP stuff seems to have been designed in a way
that makes it simple to use, which I appreciate.

However, I ran into a problem where I wasn't getting gzipped data back
from an HTTP request even when I had set the "Accept-Encoding: gzip"
header. Using curl I would get gzipped data as expected.

Digging into the source code of http.c I discovered the reason. My jaw
is still hanging slackly.

Here's the relevant segment of code:
------------------
/*
* Create the headers need for an HTTP request
*/
static void
evhttp_make_header_request(struct evhttp_connection *evcon,
   struct evhttp_request *req)
{
char line[1024];
const char *method;

evhttp_remove_header(req->output_headers, "Accept-Encoding");
evhttp_remove_header(req->output_headers, "Proxy-Connection");
-------------

Note the line: evhttp_remove_header(req->output_headers, "Accept-Encoding");

That line automatically strips out the Accept-Encoding header that I
(Continue reading)

Permalink | Reply | 0 comments |
headers
Scott Lamb | 12 Aug 2008 16:45

Re: getting notification of an evhttp_request being freed unexpectedly

Alex Evans wrote:
> hello. I'm fairly new to libevent and especially evhttp, so I have a query whose solution may just be 'dont
use evhttp that way'... the summary is: how can I know if an evhttp_request object is 'freed' behind my
back, and avoid using it after it's dead?
> 
> I'm writing a simple single threaded libevent based http server that occasionally can't immediately
respond to an incoming http request that has been passed into a generic handler callback. instead it just
saves the evhttp_request pointer in my own list structure, and doesn't immediately call
evhttp_send_reply or equivalent. instead it falls back to the main dispatch loop and lets other events happen.
> some time later another event allows me to fill in a reply to the old request, and so I call
evhttp_send_reply on the stored request pointer.
> my issue is, that looking at the http.c code there are a few ways that the http_request I am storing a pointer
to, could be freed. for example, if the incoming connection to a server goes away, it deletes all the
outstanding requests. however my code won't get any notification that the connection or requests have
gone away, so I will merrily (later on) make use of the request pointer after it's been freed.
> what should I do? not use this pattern? use some callback mechanism I've missed? worry less? or patch
evhttp_request_free() to call an optional callback?

(Oops; resending with the list cced)

I believe you are exactly right and that this is an evhttp bug/API 
design flaw.

I've been working (off and on) on code with the same problem. It's a 
proxy server which streams results from the upstream (to which it acts 
as a client) to the downstream (to which it acts as a server). Thus, it 
also can't immediately respond to the downstream's request and has this 
window in which it assumes the evhttp_requests will not go away. 
Sometimes they do, and it crashes or at least behaves oddly. (In 
fairness, I'm not 100% sure this happens without some of the patches
(Continue reading)

Permalink | Reply | 2 comments |
headers
Scott Kevill | 13 Aug 2008 08:37

Custom allocators?

Is anything planned for libevent to allow custom allocators?

Niels posted this back in April, but it didn't make much sense since  
the function isn't mentioned anywhere else:

> You could try to use event_set_mem_functions() to change the functions
> that libevent uses for memory allocation internally.

http://monkeymail.org/archives/libevent-users/2008-April/001220.html

I may have to use __malloc_hook on Linux, but that's obviously not  
ideal as it is going to hook all allocations and it's not portable  
solution.

Scott.
--

-- 
Scott Kevill
GameRanger Technologies
http://www.GameRanger.com
multiplayer online gaming services
Permalink | Reply | 1 comment |

Gmane