Grapevine Implementation Without HttpListener

[scottoffen]

User @gustavotoyota asked back on GV4 if there was a version of Grapevine that didn't depend on http.sys or HttpListener. There isn't...yet. I'm designing GV5 in such a way that an implementation could be built that doesn't have that dependency, and user @jchristn has offered a possible solution.

The .NET team has been clear that HttpListener is maintenance-only/obsolete, and their suggested alternative is to use Kestrel. I haven't looked closely enough at Kestrel to see if it would conflict with two of the primary goals of Grapevine, specifically simple and embeddable. And I don't want Kestrel to do the routing, that's the whole point of Grapevine.

So, if someone is looking for something that handles routing for HttpListener, look no further than Grapevine. But for those who want all the yumminess of Grapevine, but either don't care what it runs on top of or specifically don't or can't use HttpListener because of it's limitations, I'd like to explore options.

To do this, we'd need to create implementations of IRestServer and IHttpContext that are not dependent on HttpListener, while still providing the same basic feature set of listening on a port/ports for incoming requests, and asynchronously handing that request/response object off to the rest of Grapevine. Oh, and the certification stuff for SSL.

Thoughts? Comments? Ideas?

[jchristn]

Hi @scottoffen - Kestrel is quite heavy and from what I gather pulls a lot of dependencies in. I have a reference implementation of a TCP-based HTTP listener that constructs a context (not compatible with the HttpListenerContext we all know and love). Something like this could be ported in such a way to provide consistency with the plumbing on which Grapevine is built.

HttpRequest - https://github.com/jchristn/HttpServerLite/blob/master/HttpServerLite/HttpRequest.cs - reads from an underlying socket and constructs the HTTP request

Webserver - https://github.com/jchristn/HttpServerLite/blob/master/HttpServerLite/Webserver.cs - see the ClientConnected method at line 389

This uses a TCP library I've built which gives explicit socket read/write control and exposes events.

If you feel there would be value in implementing something that replaces the objects that are exposed in the http.sys case I'd be open to investigating.

[scottoffen]

I'll take a look.

[jchristn]

The logic in ClientConnected (found in Webserver.cs around line 389) will read 18 characters (minimum HTTP request size, i.e. GET / HTTP1.1\r\n) from the underlying socket, and continue reading in 1-byte increments until the last 4-bytes of the string builder it is populating contain \r\n\r\n.

From there, the HttpContext object is populated, which populates the underlying HttpRequest, which is built by parsing the aforementioned string.

The data thereafter is left in the stream to be consumed by the user's application, unless they access the HttpRequest.Data property, which will read the stream in its entirety, or, they can use the DataStream property to access the stream directly. DataAsString() will also read the stream in its entirety, converting it to a string, and there is a method for JSON as well. (these are all in https://github.com/jchristn/HttpServerLite/blob/master/HttpServerLite/HttpRequest.cs)

I'm sorry I haven't gone through the Grapevine code yet, but if you can recommend the objects on which you normally work (I assume something like HttpListenerContext) I can see what it would take to map my objects to those.

Thoughts?

[scottoffen]

I haven't had a chance to dig into this more yet, but it looks promising.

[scottoffen]

In preparation for this, I've taken all of the code that doesn't depend on HttpListener and moved it into a library available on NuGet called Grapeseed (note that the namespace will still be Grapevine in the package, not Grapeseed). The interfaces for IHttpContext and IRestServer are there, however neither is implemented. Grapevine will now depend on Grapeseed.

Other implementations can include Grapeseed to get all of the Router/Route/RouteScanner functionality, and then choose whether or not to implement IRestServer, but they will need to implement IHttpContext and it's component interfaces IHttpRequest and IHttpResponse.

Most of this is already available in 5.0.0-rc.7, the rest will be completed in the next release. Once a 5.0 release is published, I'll begin looking into alternate implementation that don't wrap HttpListener.

[jchristn]

Got it. Let me dig into that and see what I can come up with. I'll package it separately, test it with HttpServerLite, and report back. Cheers

[jchristn]

Can you add targeting for net461 to Grapeseed?

[jchristn]

Also need some feedback. Quite a few differences in implementation between what I've done in HttpServerLite vs what you need in the HttpContext for Grapevine/Grapeseed. There are a few properties I capture/expose in HttpRequest that you don't use, and some that you expose that I'm not sure how to populate.

• ContentEncoding shows it maps to System.Text.Encoding - I'm assuming you have a class/method that manages this translation?
• HostPrefix - are you referring to the prefix on which the server received the request? i.e. http://localhost:8000/
• Name - unsure how you use this or how you populate it
• Endpoint - need an example
• PathParameters - would this be the raw URL split by '/'? Unsure, because it's a Dictionary
• RawUrl - assuming you mean /foo/bar when the full URL is http://localhost:8000/foo/bar
• UserHostAddress - requestor IP address? IP:port?
• UserHostname - I'm assuming same as UserHostAddress but only just the IP, unless you are proactively doing a Dns.GetHostEntry() for each request?

Source can be found here, I still have a long way to go to stitch it up: https://github.com/jchristn/HttpContextLite

[scottoffen]

Looking at this.

[jchristn]

Did you have a chance to take a look? I can move forward with answers on the above. Cheers