ebb wsgi ?

[Phoenix Sol]

Has anyone done any work on a python binding ?

Looks like it's worth doing... I'd like to test drive it with
stackless ;-)

[ry]

No - long ago abandoned. I have a half completed binding for python
laying around somewhere (I guess it's in the ebb repo). Might be
useful to use as a starting point for an up-to-date libebb binding.
But, no, nothing immediately useful in Python here.

[lindell]

I've just started work on this as part of a larger stackless framework
I am building. I've created a base HTTP server that spawns off each
request handler in its own tasklet. I have a highler level WSGI
server that wraps the base class and implements the WSGI protocol.
The code is only a few days old. I can run the "Hello World" sample
WSGI app from PEP 333, but the error handling is very minimal.

The problem I am running into on error handling is that I am having a
very hard time closing the connection before the request has been
fully parsed. For example, I want to set limits on how many headers I
will accept or how big the body of a request can be. If the client
exceeds these limits, I want to disconnect them immediately. Ideally,
I'd like to be able to just call ebb_connection_schedule_close() in my
on_header_* and on_body callbacks and have libebb shutdown the parser
and call may on_close handler. Then I could clean up all of the
allocated requests, headers, and such in that handler.

Unfortunately, the best I have been able to do so far is to set an
error flag during parsing which all of my parsing callbacks use as a
signal to stop processing the request. This isn't the best solution
since libebb will still keep calling my handlers and reading the
request until the client closes the connection. Any suggestions on
how I could do this better?

[Ryan Dahl]

> The problem I am running into on error handling is that I am having a
> very hard time closing the connection before the request has been
> fully parsed. For example, I want to set limits on how many headers I
> will accept or how big the body of a request can be. If the client
> exceeds these limits, I want to disconnect them immediately. Ideally,
> I'd like to be able to just call ebb_connection_schedule_close() in my
> on_header_* and on_body callbacks and have libebb shutdown the parser
> and call may on_close handler. Then I could clean up all of the
> allocated requests, headers, and such in that handler.

There isn't a way to interrupt the parser but perhaps i should add
this? like returning non-zero from a callback will stop it? You can
set your parser callbacks (in the ebb_request structure) to NULL and
nothing will happen.

[lindell]

I vote for returning non-zero to halt the parser. That is similar to
the way that the libcurl multi-interface works. It uses return codes
in the callback to signal the library.

This also seems like the most efficient way to terminate a naughty
connection. If I understand you correctly, setting the parser
callbacks to NULL would be like a NO-OP. The parser would still keep
reading data from the client and the ebb_request structure would stay
in use until the entire request has been read from the client. I'd
rather close the connection, cleanup all request and connection
structs and move on.

[ry]

On Apr 10, 5:51 pm, lindell <lindell.alder...@gmail.com> wrote:
> I vote for returning non-zero to halt the parser.  That is similar to
> the way that the libcurl multi-interface works.  It uses return codes
> in the callback to signal the library.
>
> This also seems like the most efficient way to terminate a naughty
> connection.  If I understand you correctly, setting the parser
> callbacks to NULL would be like a NO-OP.  The parser would still keep
> reading data from the client and the ebb_request structure would stay
> in use until the entire request has been read from the client.  I'd
> rather close the connection, cleanup all request and connection
> structs and move on.

I've released a separate http parser package which does do the above

http://github.com/ry/http-parser/tree/master
http://s3.amazonaws.com/four.livejournal/20090427/http_parser-0.1.tar.gz

I probably am not going to back port it to libebb.
This is being used in my new javascript work

http://github.com/ry/node/tree/master

ry