www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is there interest in a std.http?

reply "Tyler Jameson Little" <beatgammit gmail.com> writes:
I'd like to see an HTTP module in Phobos, but I wanted to gauge 
interest first and see if this has been discussed before.

An example of how I would like to interface with it (for creating 
a server):

     interface HTTPHandler {
         void serveHTTP(Request, Response);
     }

     class CustomHandler : HTTPHandler {
         ....
         void serveHTTP(Request req, Response res) {
         }
     }

     auto handler = new CustomHandler(); // implements http.Handler
     auto server = new HttpServer(handler);
     server.listen("0.0.0.0", 80);

As long as serveHttp() is thread safe, the http server could be 
concurrent or evented (with libev or similar) and the custom 
handler code wouldn't have to change.

I'm willing to put in the lion's share of the work (I've already 
written a bunch of it), but I'd naturally like to get some 
community input so I don't go in a completely wrong direction. 
I'm thinking of emulating Go's http library 
(http://golang.org/pkg/net/http), but of course D style.

I think the following are necessary:

* Access to underlying TcpSocket (for protocol upgrades, like 
WebSocket)
* HTTP body is a stream
* Simple HTTP requests
* Errors can be recovered from (allow user-defined error 
handlers):
* User settable size limits
   * Size of request line (1024 bytes by default)
   * Size of each header (1024 bytes by default)
   * Total size of header block (4096 bytes by default)

So, basically I'm looking for two things:

1. Interest level: willing to writ code, willing to test, want to 
use
2. Suggestions for the API/behavior
Nov 19 2012
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 19 November 2012 at 20:38:56 UTC, Tyler Jameson Little 
wrote:
 I'd like to see an HTTP module in Phobos, but I wanted to gauge 
 interest first and see if this has been discussed before.
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 Feel free to take whatever you want from it. There's also an extremely minimal http.d file in there, which is a very simple http client. (I didn't go far with this though because I tend to use curl for most my work anyway.) The way I did it is with a function: void handleRequest(Cgi cgi) { } And then there's a mixin called GenericMain that calls your function. mixin GenericMain!handleRequest; Depending on how you compile it, the main function constructs the cgi object differently. -version=fastcgi means it is plugged into a FastCGI loop. version=scgi ditto. -version=embedded_httpd includes a simple little threaded http server. No version builds it as a standard CGI binary, one process per request. However it is compiled though, the Cgi methods all remain the same, so your function shouldn't have to change.
 * Access to underlying TcpSocket (for protocol upgrades, like 
 WebSocket)
My cgi.d I don't think can do this yet. I've been thinking about adding it though, but haven't.
 * HTTP body is a stream
class Cgi has a method onRequestBodyDataReceived and one handleIncomingDataChunk which can be overridden by subclasses to do this kind of thing. It's a bit of a pain though, I made it thinking you'd want to handle it after it is all loaded.
 * Simple HTTP requests
This is where I think my cgi.d is a winner because most the data is available so easily cgi.get["foo"] returns a string cgi.getArray["foo"] returns an array of strings ditto for post cgi.request("foo", 0) returns with a default value, converting types as requested There's also members like cookie, queryString, host, etc., that gives nice access to other headers.
 * 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.
Nov 19 2012
parent reply "Tyler Jameson Little" <beatgammit gmail.com> writes:
 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?
Nov 19 2012
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 19 November 2012 at 23:57:35 UTC, Tyler Jameson Little 
wrote:
 Awesome. I assume this hasn't gone through rigorous testing, 
 but has it been used in production?
I've been using it for almost all my work apps for the last... I think three years now. None of them so far have huge userbases, but it has been in steady use for a while. The others in this thread have pointed out the other options that have some users: Vladimir's library that runs the forum, and vibe.d that seems to be the most popular. I haven't used either of them though.
 How do you feel about function pointer callbacks?
We could also do them as virtual functions... that's a little easier in the setup I have because the constructor arguments are messy, whereas subclassing is a lot simpler. But yeah, it sounds like a decent plan.
Nov 19 2012
prev sibling next sibling parent "Pragma Tix" <bizprac orange.fr> writes:
Before you spend too much time :
https://github.com/rejectedsoftware/vibe.d/tree/master/source/vibe/http



On Monday, 19 November 2012 at 20:38:56 UTC, Tyler Jameson Little 
wrote:
 I'd like to see an HTTP module in Phobos, but I wanted to gauge 
 interest first and see if this has been discussed before.

 An example of how I would like to interface with it (for 
 creating a server):

     interface HTTPHandler {
         void serveHTTP(Request, Response);
     }

     class CustomHandler : HTTPHandler {
         ....
         void serveHTTP(Request req, Response res) {
         }
     }

     auto handler = new CustomHandler(); // implements 
 http.Handler
     auto server = new HttpServer(handler);
     server.listen("0.0.0.0", 80);

 As long as serveHttp() is thread safe, the http server could be 
 concurrent or evented (with libev or similar) and the custom 
 handler code wouldn't have to change.

 I'm willing to put in the lion's share of the work (I've 
 already written a bunch of it), but I'd naturally like to get 
 some community input so I don't go in a completely wrong 
 direction. I'm thinking of emulating Go's http library 
 (http://golang.org/pkg/net/http), but of course D style.

 I think the following are necessary:

 * Access to underlying TcpSocket (for protocol upgrades, like 
 WebSocket)
 * HTTP body is a stream
 * Simple HTTP requests
 * Errors can be recovered from (allow user-defined error 
 handlers):
 * User settable size limits
   * Size of request line (1024 bytes by default)
   * Size of each header (1024 bytes by default)
   * Total size of header block (4096 bytes by default)

 So, basically I'm looking for two things:

 1. Interest level: willing to writ code, willing to test, want 
 to use
 2. Suggestions for the API/behavior
Nov 19 2012
prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Monday, 19 November 2012 at 20:38:56 UTC, Tyler Jameson Little 
wrote:
 * HTTP body is a stream
No Content-Size, no multiple requests per connection (unless you use chunked encoding?).
 * User settable size limits
   * Size of request line (1024 bytes by default)
   * Size of each header (1024 bytes by default)
   * Total size of header block (4096 bytes by default)
I think this is pointless. Use an appender and the RFC limits. Unless you are serving VERY simple pages, the cost of a few allocations for handling the HTTP protocol's overhead will not be noticeable compared to the application's. (Slowloris is something to keep in mind, though.) My HTTP library, which is used for this forum and several other "production" projects, is here: https://github.com/CyberShadow/ae The main problem with getting it into Phobos is that it's tied to a lot of other related code, such as the asynchronous sockets module, the unmanaged memory wrapper type, etc. Also, what about vibe.d?
Nov 19 2012
parent reply "Tyler Jameson Little" <beatgammit gmail.com> writes:
 * HTTP body is a stream
No Content-Size, no multiple requests per connection (unless you use chunked encoding?).
Not sure what you mean. I meant incoming stream. There would be a request object with access to all other headers, it just wouldn't be read in until the user actually wanted it.
 * User settable size limits
  * Size of request line (1024 bytes by default)
  * Size of each header (1024 bytes by default)
  * Total size of header block (4096 bytes by default)
I think this is pointless. Use an appender and the RFC limits. Unless you are serving VERY simple pages, the cost of a few allocations for handling the HTTP protocol's overhead will not be noticeable compared to the application's. (Slowloris is something to keep in mind, though.)
I just made up those limits, but the point is I'd like the user to be able to tweak those. The default will work for most people though.
 My HTTP library, which is used for this forum and several other 
 "production" projects, is here: 
 https://github.com/CyberShadow/ae
 The main problem with getting it into Phobos is that it's tied 
 to a lot of other related code, such as the asynchronous 
 sockets module, the unmanaged memory wrapper type, etc.
Cool, I didn't know that this was served by D code. I'll take a look at it.
 Also, what about vibe.d?
vibe.d does a lot of things, and it probably does those things very well. It seems well maintained, and generally a good project. I think that a lot of the things it does well could be brought into the standard library. As this thread pointed out, there are several HTTP parsers floating around out there. For some, vibe.d might not be a perfect fit for whatever reason, but everyone can benefit from a simple HTTP library. Maybe it shouldn't be as high-level as Go's http library, but it should at least make writing a simple HTTP server trivial. Would a minor refactor of vibe.d be acceptable? This is pretty much what I'm looking for: https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/http/common.d https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/http/server.d Except that I'd remove some parts of it, like JSON parsing. I think that vibe.d could benefit from moving some of the code there into Phobos. I guess it comes down to whether it makes sense to make a standard HTTP library.
Nov 19 2012
parent reply "Nicolas Sicard" <dransic gmail.com> writes:
On Tuesday, 20 November 2012 at 03:49:57 UTC, Tyler Jameson 
Little wrote:
 Would a minor refactor of vibe.d be acceptable? This is pretty 
 much what I'm looking for:

 https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/http/common.d
 https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/http/server.d

 Except that I'd remove some parts of it, like JSON parsing.

 I think that vibe.d could benefit from moving some of the code 
 there into Phobos. I guess it comes down to whether it makes 
 sense to make a standard HTTP library.
BTW, the actual JSON module in viba.data.json in richer in functionality and easier to use than the one in std.json. The module has virtually no dependency on other parts of vibe.d. I whish it was also moved to Phobos or at least inspired a refactoring of std.json. Nicolas
Nov 20 2012
next sibling parent "Pragma Tix" <bizprac orange.fr> writes:
On Tuesday, 20 November 2012 at 12:12:27 UTC, Nicolas Sicard 
wrote:
 On Tuesday, 20 November 2012 at 03:49:57 UTC, Tyler Jameson 
 Little wrote:
 Would a minor refactor of vibe.d be acceptable? This is pretty 
 much what I'm looking for:

 https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/http/common.d
 https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/http/server.d

 Except that I'd remove some parts of it, like JSON parsing.

 I think that vibe.d could benefit from moving some of the code 
 there into Phobos. I guess it comes down to whether it makes 
 sense to make a standard HTTP library.
BTW, the actual JSON module in viba.data.json in richer in functionality and easier to use than the one in std.json. The module has virtually no dependency on other parts of vibe.d. I whish it was also moved to Phobos or at least inspired a refactoring of std.json. Nicolas
vibe.d is MIT licensed. (Like almost every other WEB related library) Guess you have to ask Soenke for a permission.
Nov 20 2012
prev sibling parent "Rob T" <rob ucora.com> writes:
On Tuesday, 20 November 2012 at 12:12:27 UTC, Nicolas Sicard 
wrote:
 BTW, the actual JSON module in viba.data.json in richer in 
 functionality and easier to use than the one in std.json. The 
 module has virtually no dependency on other parts of vibe.d. I 
 whish it was also moved to Phobos or at least inspired a 
 refactoring of std.json.

 Nicolas
I have not yet looked at the vibe.d JSON yet, but I certainly will. I agree with you that the std.json could use some improvement, it's not all that fun to use that's for sure. --rt
Nov 20 2012
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/19/12 3:38 PM, Tyler Jameson Little wrote:
 I'd like to see an HTTP module in Phobos, but I wanted to gauge interest
 first and see if this has been discussed before.
I can say the following. We sorely need a server expert on board with the time and inclination to write a good server-side networking framework. We have a couple, but for various reasons I have been unable to convince them (through newsgroup and private exchanges) to invest time in such an endeavor. That's mostly because lack of time - speaking for myself, I wish I found the time to learn about all that, which as far as I understand gravitates around notions such as asynchronous I/O, libevent/libevt, select(), and the such. I've never used them so I'd need to start from scratch. We really need an expert. Look at the Go programming language - it's not remarkable, but it benefits of full-time dedication of experts in server-side programming, so it has acquired excellent library support for networking servers. And they milk that for all it's worth: any discussion, article, or blog post about Go gravitates toward the five-lines HTTP server with the same implacable reach as conversations with ideologists, which inevitably converge towards their ideological stronghold. Andrei
Nov 19 2012
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/19/12 11:26 PM, Andrei Alexandrescu wrote:
 On 11/19/12 3:38 PM, Tyler Jameson Little wrote:
 I'd like to see an HTTP module in Phobos, but I wanted to gauge interest
 first and see if this has been discussed before.
I can say the following. We sorely need a server expert on board with the time and inclination to write a good server-side networking framework.
To clarify (lest this would be interpreted as excluding vibe.d from the category of good server-side networking frameworks): ... for inclusion in the standard library. Andrei
Nov 19 2012
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 20 November 2012 at 04:26:02 UTC, Andrei Alexandrescu 
wrote:
 We sorely need a server expert on board with the time and 
 inclination to write a good server-side networking framework.
I agree with this but it really should be generic; working at probably the file descriptor level, so we can do whatever protocols along with files, pipes, ... and ideally, any kind of injected event. I'd really like it if we could run one event loop and be able to do keyboard/joystick input, timers, GUI, threads, etc., including third party libraries, as well as networking. (Combining two different event loops is a pain in the butt.) I have an implementation in mind (I'd use select() because I don't know libev, but we should be able to change that without changing the interface)... ... but I'm behind on my other work and have yet another deadline looming so can't do it myself right now. I can't wait till I'm retired!
 And they milk that for all it's worth: any discussion, article, 
 or blog post about Go gravitates toward the five-lines HTTP 
 server with the same implacable reach as conversations with 
 ideologists, which inevitably converge towards their 
 ideological stronghold.
You know, I'll never understand this. Anybody can do a five line http server. Hell, with my lib: import arsd.cgi; void hello(Cgi cgi) { cgi.write("hello!"); } mixin GenericMain!hello; Look, tiny http server (on port 8080)! Also works as cgi, fastcgi, scgi, and easy command line testing with a different compile option. But not really that special language wise... yay, you can call a library function. Who can't do that?
Nov 20 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Nov 20, 2012 at 03:09:23PM +0100, Adam D. Ruppe wrote:
 On Tuesday, 20 November 2012 at 04:26:02 UTC, Andrei Alexandrescu
 wrote:
We sorely need a server expert on board with the time and
inclination to write a good server-side networking framework.
I agree with this but it really should be generic; working at probably the file descriptor level, so we can do whatever protocols along with files, pipes, ... and ideally, any kind of injected event. I'd really like it if we could run one event loop and be able to do keyboard/joystick input, timers, GUI, threads, etc., including third party libraries, as well as networking. (Combining two different event loops is a pain in the butt.)
The event loop itself should be a generic component in Phobos, not specific to anything else. It should work at the file descriptor level, perhaps even combining with signal handling (using the self-pipe trick), and handle timers and scheduled events as well. Everything else should be pluggable into this generic module. I have written such things before in C/C++, but in D this will be much easier to implement, thanks to delegates (which make writing event-loop based programs so much less painful). Having a standard event loop will make it much less painful to integrate many components together in a seamless way. Combining two event loops, as Adam says, is a royal pain in the neck. Making the generic event loop a Phobos standard will eliminate this problem.
 I have an implementation in mind (I'd use select() because I don't
 know libev, but we should be able to change that without changing
 the interface)...
The interface should be generic enough that you don't have to worry about whether select or poll (or whatever the windows equivalent is) is used. I think it's a good idea to implement the select version first, as that's generic across Posixes, whereas libev is Linux-specific IIRC. T -- 2+2=4. 2*2=4. 2^2=4. Therefore, +, *, and ^ are the same operation.
Nov 20 2012
next sibling parent "jerro" <a a.com> writes:
 whereas libev is Linux-specific IIRC.
Libev is a polling abstraction. It has select, epoll and kqueue backends (and there may be others I don't know about). So it is particulary useful for unices, where epoll (linux) and kqueue (OSX and BSD) are preferred async IO mechanisms. It can also be used on Windows, but with the select() backend, which doesn't scale well with many file descriptors. select() is also limited to 64 file descriptors by default on windows IIRC (that limit can be raised, but only to 4096 if I am not mistaken).
Nov 20 2012
prev sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 20 November 2012 at 15:21:12 UTC, H. S. Teoh wrote:
 It should work at the file descriptor level, perhaps even
 combining with signal handling (using the self-pipe trick)
I was thinking we'd send pointers and a type hash through a pipe. It'd keep the read/write very simple. Now, the event data must be defined to be transient, unless specifically told otherwise (e.g. immutable types), because then we can reuse the data structures to avoid allocations. But take a gander at this: http://arsdnet.net/dcode/typehash.d We can take any type tuple, do a mangle of and get a unique name for any combination of arguments. Then hash it, and we have a nicely unique, fixed size message to send down the pipe. One one end, we'll cast to a void* and send that along with the hash. On the other side, only listener functions who's ParameterTypeTuple matches the typehash will receive a message. They can then cast the void* back to the argument type with confidence. This lets us define custom messages as plain types: struct MyMessage { string text; } event.listen((MyMessage m) { writeln("Received: ", m.text); } event.send(MyMessage("hello!")); event.loop(); // we should receive the message and call the above func If there's no listener that matches the hash, we ignore the message. Now there'd be some care needed to not send pointers to stack data down the pipe, as that could be destroyed, but eh. Some details gotta be worked out but I really like the idea of using type names like this.
Nov 20 2012
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 20 November 2012 at 16:09:37 UTC, Adam D. Ruppe wrote:
 But take a gander at this:
 http://arsdnet.net/dcode/typehash.d
I have such a hard time focusing on work when there's something like this to play with.... updated the link to show the concept actually working, not just hashing. All event listeners must take exactly one argument and it is all statically typed, but it works and can do the hash+pointer message. The hash function down there is borrowed from druntime. I couldn't find it accessible as a stdlib import so I copy/pasted. But ignoring that, the rest is actually simple code. Problem is this probably isn't safe... and might not be trusted either because you can send stack info.. maybe we could do further constraints, or copy the data into a queue, or something. I really think we could make it work though and it'd be pretty cool.
Nov 20 2012
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
11/20/2012 8:26 AM, Andrei Alexandrescu пишет:
 On 11/19/12 3:38 PM, Tyler Jameson Little wrote:
 I'd like to see an HTTP module in Phobos, but I wanted to gauge interest
 first and see if this has been discussed before.
I can say the following. We sorely need a server expert on board with the time and inclination to write a good server-side networking framework. We have a couple, but for various reasons I have been unable to convince them (through newsgroup and private exchanges) to invest time in such an endeavor. That's mostly because lack of time - speaking for myself, I wish I found the time to learn about all that, which as far as I understand gravitates around notions such as asynchronous I/O, libevent/libevt, select(), and the such. I've never used them so I'd need to start from scratch.
Having done quite some work on this before - both with frameworks and barehanded. The recipe for scalable and fast server itself is not that hard: asynchronous I/O + event-based notification + separate thread pool for user-defined handlers Asynchronous I/O is well understood to have far less overhead then thread per client/descriptor model. Both in terms of memory usage and time spent on the context switching. Event based notification can be traded for select() polling but then you'd waste a lot of cycles (in kernel mode) walking through huge descriptor sets when number of simultaneous clients is high enough. A separate "worker" thread pool insures your event-loop is not ever blocked thus insuring responsiveness w.r.t dispatching I/O requests. Arguably this could be an opt-in. If this combo is implemented even half-decently it should give us great speed. The fine-tuning and topping the performance however is the other 70% of work and that makes the real difference. The devil is in the details. Not to mention fiddling with socket options and imposing limits on transfer rate/timeouts etc. I currently had to work with Java (a painful journey after D) to create a couple of server components and surprisingly found the Netty project to be quite nice. Though being overly Java-escue it has some great ideas (aside from the above basic concepts): - The composable pipeline abstraction that allows passing user data through a series of transformations seamlessly. Think the stack of TCP|HTTP|encryption/compression or TCP|framing|ProtocolBuffers etc. - Flexible and zero-copy (quite hard for Java I guess) buffer abstraction. It reminds the power of ranges but in a heck of a more limited scale - it's more about chaining and slicing. These limitations are mostly because of the way the OS works.
 We really need an expert. Look at the Go programming language - it's not
 remarkable, but it benefits of full-time dedication of experts in
 server-side programming, so it has acquired excellent library support
 for networking servers.
Can help with a proper asynchronous (network) I/O support on Windows. I doubt I'll find time to flesh out the whole design though. What it irks me that I haven't seen a good enough backend for Windows in the open source (of those I've peeked at the source of). A lot of event-based backends seem to just ignore this OS or fallback to select-loop. Meanwhile M$ introduced the new RIO socket API targeted at high-load servers. Was planing to try it out since the day it was introduced.
 And they milk that for all it's worth: any
 discussion, article, or blog post about Go gravitates toward the
 five-lines HTTP server with the same implacable reach as conversations
 with ideologists, which inevitably converge towards their ideological
 stronghold.
I see no reason we can't beat them in their favorite game. -- Dmitry Olshansky
Nov 20 2012
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
11/20/2012 11:45 PM, Dmitry Olshansky пишет:
[snip]


 I currently had to work with Java (a painful journey after D) to create
 a couple of server components and surprisingly found the Netty project
 to be quite nice.
The obligatory link: https://netty.io/ -- Dmitry Olshansky
Nov 20 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-11-19 21:38, Tyler Jameson Little wrote:

 I think the following are necessary:

 * Access to underlying TcpSocket (for protocol upgrades, like WebSocket)
 * HTTP body is a stream
 * Simple HTTP requests
 * Errors can be recovered from (allow user-defined error handlers):
 * User settable size limits
    * Size of request line (1024 bytes by default)
    * Size of each header (1024 bytes by default)
    * Total size of header block (4096 bytes by default)
* HTTPS -- /Jacob Carlborg
Nov 19 2012