Is there interest in a std.http?

[Tyler Jameson Little]

> I've been asked to put my cgi.d in phobos before (which 
> includes a http server as well as a cgi, fastcgi, and scgi 
> implementation of its common interface), so there's probably 
> some interest.
>
> I haven't put mine in just because I'm not particularly 
> motivated to go through the red tape.
>
> The file is cgi.d in here:
> https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff

Awesome. I assume this hasn't gone through rigorous testing, but 
has it been used in production?

>> * Errors can be recovered from (allow user-defined error 
>> handlers):
>> * User settable size limits
>
> eh, I'm partially there on these. There's some constructor args 
> you can play with and some degree of exception catching but 
> probably not fully what you have in mind.

I'm thinking of something a little more sophisticated than 
exceptions. Exceptions unwind the stack, so you can't just 
continue where you left off.

How do you feel about function pointer callbacks? The http parser 
in node.js (https://github.com/joyent/http-parser) takes a struct 
of function pointers to handle errors/events. When the parser 
encounters a recoverable error (max header length reached), the 
programmer could opt to ignore it and continue the parse. 
Unrecoverable errors could throw exceptions (like trying to parse 
garbage data).

If an error is recovered, it would just continue as if nothing 
happened.

Of course, implementing this would increase complexity in the 
parser, but I think it's justified. Thoughts?