[swift-server-dev] HTTP Parser

Thu Nov 3 15:27:33 CDT 2016

I think one thing that needs to be considered is HTTP/2 support - 
implementing HTTP/2 is significantly more complex that HTTP 1.x, so if we 
want to support HTTP/2 it may make more sense to look at what we can reuse 
(the nghttp2 library?)

Chris 

From:   Tanner Nelson via swift-server-dev <swift-server-dev at swift.org>
To:     Logan Wright <logan at qutheory.io>
Cc:     Swift Server Dev <swift-server-dev at swift.org>
Date:   03/11/2016 18:51
Subject:        Re: [swift-server-dev] HTTP Parser
Sent by:        swift-server-dev-bounces at swift.org

I think it's important to remember that performance is not the only 
concern.

If we need to use the node_http parser because of time constraints, I'd 
prefer that over creating a non-Swifty copy. If you want the functionality 
of UnsafePointers, C is the better language to be working in.

Going forward I think a Swifty HTTP parser could get decent performance. 
More importantly though it would be incredibly concise, readable, and 
maintainable.

Tanner Nelson
Vapor 
+1 (435) 773-2831

On Nov 3, 2016, at 2:42 PM, Logan Wright via swift-server-dev <
swift-server-dev at swift.org> wrote:

Completely agree Alex, I also feel strongly about the language in general, 
and I think if we're going to take the time to build out Swift server 
apis, they should be in well, Swift.

In terms of performance, Swift will only continue to improve in 
performance, and given our access to the compiler team and the smart minds 
in this room. I think we can beat the node parser with time.

- Logan

On Thu, Nov 3, 2016 at 2:41 PM Alfredo Delli Bovi <
alfredo.dellibovi at gmail.com> wrote:
Hi people,

There has been some discussions about this in Kitura already (
https://github.com/IBM-Swift/Kitura-net/issues/52) and I think we can use 
what they found out at the moment.
In my opinion, if we are not able to give the same (or better) performance 
we should go for a wrapper of a more performant lib, such as http_parser.

Of course it’s also matter of the workload that have, we could always 
start with a wrapper, so we are able to define the APIs layer and ship a 
version with it and later on changing the implementation with a pure 
Swift.

—

Alfredo Delli Bovi 

On 3 Nov 2016, at 19:35, Logan Wright via swift-server-dev <
swift-server-dev at swift.org> wrote:

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
_______________________________________________
swift-server-dev mailing list
swift-server-dev at swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev

_______________________________________________
swift-server-dev mailing list
swift-server-dev at swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev
_______________________________________________
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/f607d331/attachment.html>