[swift-server-dev] HTTP Parser
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
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?:
> 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:
> 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):
> 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 :-)
> swift-server-dev mailing list
> swift-server-dev at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-server-dev