[swift-server-dev] HTTP Parser

Logan Wright logan at qutheory.io
Thu Nov 3 13:35:10 CDT 2016

Helge, definitely depends on the underlying network/dispatch scheme that we
go with. I doubt we'd pull in my original code 1:1. But it does speak to my
experience w/ the RFC spec in particular.

I'd personally opt for pure-swift over c-wrapper. I think it will be easier
to maintain/deploy/optimize going forward. I don't have an inherent problem
w/ the nodejs parser aside from that if people strongly prefer to use
c-code here.

- Logan

On Thu, Nov 3, 2016 at 1:27 PM Helge Heß via swift-server-dev <
swift-server-dev at swift.org> wrote:

> Hi Logan,
> On 03 Nov 2016, at 17:50, Logan Wright <logan at qutheory.io> wrote:
> > Yup, you can see a lot of it in the underlying engine module from Vapor.
> is it this one?:
> https://github.com/vapor/engine/blob/master/Sources/HTTP/Parser/HTTPParser.swift
> that seems to be a pull based / blocking parser, right? That probably
> doesn’t work for a lot of environments.
> Personally I’d suggest a small wrapper around this one:
>   https://github.com/nodejs/http-parser
> It is small, fast, highly efficient, zero copy, push based, supports
> chunked&upgrade and is extremely well tested and widely deployed.
> I also did a straight port of that to Swift, though if you can use the C
> version I wouldn't use the port as it is significantly slower (and may have
> extra bugs introduced during the port):
>   https://github.com/NozeIO/Noze.io/tree/master/Sources/http_parser
> My approach here was to keep it close to the original, which makes for
> really ugly code :-)
> I think it may be worthwhile to do another attempt of a port of the
> parser, but less 1:1 like mine, in a Swiftier way (the original uses a lot
> of goto’s :-).
> As mentioned, I wouldn’t expect people to use the low level API but rather
> have nice objects filled by the underlying parser. What about `WORequest` &
> `WOResponse`? :-)
> BTW: Something I consider important to discuss across all areas of
> interest (crypto, sockets, HTTP) is a protocol to represent a chunks of
> bytes and chunks of chunks of bytes (buckets and brigades in Apache terms).
> Of course that could be just NSData or DispatchData but I expect that some
> frameworks have their own way to represent such buffers, hence a protocol
> would be nice.
> Why important? Well, because there needs to be a way to pass the data
> between those components w/o copying it :-)
> hh
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20161103/cc07f2a5/attachment.html>

More information about the swift-server-dev mailing list