[swift-server-dev] HTTP Parser

[Tony Parker]

> On Nov 3, 2016, at 1:27 PM, Chris Bailey via swift-server-dev <swift-server-dev at swift.org> wrote:
> 
> > 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 :-) 
> 
> I think Data/NSData probably makes most sense here, because the data is likely to be passed from the frameworks onto wider sets of packages, which are likely to use NSData - so the overall consistency reduces the overhead of copying and/or translating data types etc. 
> 
> That said, there's some performance work that I know needs doing in Data/NSData, which means frameworks that use their own data types are (today) faster in that area.

This is something we’re actively looking into, actually.

- Tony

> 
> 
> 
> 
> From:        Helge Heß via swift-server-dev <swift-server-dev at swift.org <mailto:swift-server-dev at swift.org>> 
> To:        Swift Server Dev <swift-server-dev at swift.org <mailto:swift-server-dev at swift.org>> 
> Date:        03/11/2016 17:27 
> Subject:        Re: [swift-server-dev] HTTP Parser 
> Sent by:        swift-server-dev-bounces at swift.org <mailto:swift-server-dev-bounces at swift.org> 
> 
> 
> 
> 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 <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 <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 <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
> 
> [attachment "signature.asc" deleted by Chris Bailey/UK/IBM] _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org <mailto:swift-server-dev at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-server-dev <https://lists.swift.org/mailman/listinfo/swift-server-dev>
> 
> 
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org <mailto:swift-server-dev at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-server-dev <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/371cf475/attachment.html>