[swift-server-dev] HTTP Parser

[Chris Bailey]

> 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.




From:   Helge Heß via swift-server-dev <swift-server-dev at swift.org>
To:     Swift Server Dev <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



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

[attachment "signature.asc" deleted by Chris Bailey/UK/IBM] 
_______________________________________________
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/bf8933ee/attachment.html>