HTTP API proposal for TLS integration

Hi all,

As part of PR#78 for TLS integration into HTTP,
TLS integration by gtaban · Pull Request #78 · swift-server/http · GitHub, I had to update the HTTP API
and would like to ask for feedback.

The TLS code sits in:
GitHub - gtaban/security: Repository for the development of cross-platform Security APIs // protocol definitions and
data types
GitHub - gtaban/TLSService: SSL/TLS Add-in for BlueSocket using Secure Transport and OpenSSL // implementation using OpenSSL
on Linux and SecureTransport on macOS

The proposed HTTP API changes are in HTTPServing protocol:

     /// Start the HTTP server on the given `port`, using `handler` to
process incoming requests
- func start(port: Int, handler: @escaping HTTPRequestHandler) throws

+ func start(port: Int, tls: TLSConfiguration?, handler: @escaping
HTTPRequestHandler) throws

and HTTPServer class `start()` function:

- public func start(port: Int = 0, handler: @escaping
HTTPRequestHandler) throws {
- try server.start(port: port, handler: handler)

+ public func start(port: Int = 0, tls: TLSConfiguration? = nil,
handler: @escaping HTTPRequestHandler) throws {
+ try server.start(port: port, tlsConfig: tls, handler: handler)

TLSConfiguration is a struct defined in:

which stores TLS parameters that are needed to configure a TLS connection.
These include credentials (certificates and passwords) and cipher suites.

There is a corresponding change in PoCSocket/PoCSocketSimpleServer.swift
`start()` to pass in the configuration.

The way that the proposed APIs would get uses can be seen in
Tests/HTTPTests/TLSServerTests.swift.

        let config = createCASignedTLSConfig()

        // HTTP
        try server.start(port: 0, handler: simpleHelloWebApp.handle)

        // HTTPS
        try server.start(port: 0, tls: config, handler:
simpleHelloWebApp.handle)

Regards,
Gelareh

Good points on the existing design (without TLS). I worked with what was
there, but in general I like the idea of having an options class, which
gets set in `init`. Kind of like what we did with TLSConfiguration.

I can't comment on the parser/writer design and the multi-port, perhaps
@Chris Bailey?

gelareh

···

From: Helge Heß via swift-server-dev <swift-server-dev@swift.org>
To: Helge Heß via swift-server-dev <swift-server-dev@swift.org>
Date: 10/30/2017 12:06 PM
Subject: Re: [swift-server-dev] HTTP API proposal for TLS integration
Sent by: swift-server-dev-bounces@swift.org

Hi,

a few things I noticed working on it:

- IMO the closure, ports and stuff should go into the `init`.

- The HTTPServing thing I don’t get at all. Why do we need this?
- Kinda the same for HTTPResponseWriter. (it is particularly weird that the
writer is coupled with the parser in this implementation - they should be
completely distinct).

- `start` should maybe be called `resume`, and `stop` `suspend` to match
what GCD and Cocoa are doing.

- If we get tons of options we may rather want to add a

class HTTPServer {
  class Options { // a class because subclasses may want to add
    var certificate : ..
    var port : ...
  }
}

- Other things we need in the options: request/response logging.

- I was also wondering how we would want to handle multiple ports and in
general addresses.
You would at least want to be able to listen on IPv6 …

I can see two options here:
- either create multiple server objects for each sockaddr_in
- or add listeners to the server objects
  - this could be internal, but there needs to API to specify
    what sockaddr_in’s you want to listen on.

hh

On 30. Oct 2017, at 17:41, Gelareh Taban via swift-server-dev <swift-server-dev@swift.org> wrote:

Hi all,

As part of PR#78 for TLS integration into HTTP,

TLS integration by gtaban · Pull Request #78 · swift-server/http · GitHub, I had to update the HTTP API
and would like to ask for feedback.

The TLS code sits in:
GitHub - gadphly/swift_server_security: Repository for the development of cross-platform Security APIs // protocol definitions and data

types

GitHub - gtaban/TLSService: SSL/TLS Add-in for BlueSocket using Secure Transport and OpenSSL // implementation using OpenSSL

on Linux and SecureTransport on macOS

The proposed HTTP API changes are in HTTPServing protocol:

/// Start the HTTP server on the given `port`, using `handler` to process

incoming requests

- func start(port: Int, handler: @escaping HTTPRequestHandler) throws

+ func start(port: Int, tls: TLSConfiguration?, handler: @escaping

HTTPRequestHandler) throws

and HTTPServer class `start()` function:

- public func start(port: Int = 0, handler: @escaping HTTPRequestHandler)

throws {

- try server.start(port: port, handler: handler)

+ public func start(port: Int = 0, tls: TLSConfiguration? = nil, handler:

@escaping HTTPRequestHandler) throws {

+ try server.start(port: port, tlsConfig: tls, handler: handler)

TLSConfiguration is a struct defined in:

which stores TLS parameters that are needed to configure a TLS

connection. These include credentials (certificates and passwords) and
cipher suites.

There is a corresponding change in PoCSocket/PoCSocketSimpleServer.swift

`start()` to pass in the configuration.

The way that the proposed APIs would get uses can be seen in

Tests/HTTPTests/TLSServerTests.swift.

let config = createCASignedTLSConfig()

// HTTP
try server.start(port: 0, handler: simpleHelloWebApp.handle)

// HTTPS
try server.start(port: 0, tls: config, handler: simpleHelloWebApp.handle)

Regards,
Gelareh
_______________________________________________
swift-server-dev mailing list
swift-server-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev

[attachment "signature.asc" deleted by Gelareh Taban/Austin/IBM]
_______________________________________________
swift-server-dev mailing list
swift-server-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev

Hi,

a few things I noticed working on it:

- IMO the closure, ports and stuff should go into the `init`.

- The HTTPServing thing I don’t get at all. Why do we need this?
- Kinda the same for HTTPResponseWriter. (it is particularly weird that the writer is coupled with the parser in this implementation - they should be completely distinct).

- `start` should maybe be called `resume`, and `stop` `suspend` to match what GCD and Cocoa are doing.

- If we get tons of options we may rather want to add a

class HTTPServer {
  class Options { // a class because subclasses may want to add
    var certificate : ..
    var port : ...
  }
}

- Other things we need in the options: request/response logging.

- I was also wondering how we would want to handle multiple ports and in general addresses.
You would at least want to be able to listen on IPv6 …

I can see two options here:
- either create multiple server objects for each sockaddr_in
- or add listeners to the server objects
  - this could be internal, but there needs to API to specify
    what sockaddr_in’s you want to listen on.

hh

···

On 30. Oct 2017, at 17:41, Gelareh Taban via swift-server-dev <swift-server-dev@swift.org> wrote:

Hi all,

As part of PR#78 for TLS integration into HTTP, TLS integration by gtaban · Pull Request #78 · swift-server/http · GitHub, I had to update the HTTP API and would like to ask for feedback.

The TLS code sits in:
GitHub - gadphly/swift_server_security: Repository for the development of cross-platform Security APIs // protocol definitions and data types
GitHub - gtaban/TLSService: SSL/TLS Add-in for BlueSocket using Secure Transport and OpenSSL // implementation using OpenSSL on Linux and SecureTransport on macOS

The proposed HTTP API changes are in HTTPServing protocol:

/// Start the HTTP server on the given `port`, using `handler` to process incoming requests
- func start(port: Int, handler: @escaping HTTPRequestHandler) throws

+ func start(port: Int, tls: TLSConfiguration?, handler: @escaping HTTPRequestHandler) throws

and HTTPServer class `start()` function:

- public func start(port: Int = 0, handler: @escaping HTTPRequestHandler) throws {
- try server.start(port: port, handler: handler)

+ public func start(port: Int = 0, tls: TLSConfiguration? = nil, handler: @escaping HTTPRequestHandler) throws {
+ try server.start(port: port, tlsConfig: tls, handler: handler)

TLSConfiguration is a struct defined in:
https://github.com/gtaban/security/blob/master/Sources/ServerSecurity/TLSConfiguration.swift

which stores TLS parameters that are needed to configure a TLS connection. These include credentials (certificates and passwords) and cipher suites.

There is a corresponding change in PoCSocket/PoCSocketSimpleServer.swift `start()` to pass in the configuration.

The way that the proposed APIs would get uses can be seen in Tests/HTTPTests/TLSServerTests.swift.

let config = createCASignedTLSConfig()

// HTTP
try server.start(port: 0, handler: simpleHelloWebApp.handle)

// HTTPS
try server.start(port: 0, tls: config, handler: simpleHelloWebApp.handle)

Regards,
Gelareh
_______________________________________________
swift-server-dev mailing list
swift-server-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev

Helge,

Can you review the following PRs and see if they cover some of the issues
you raised about

- `start` called `resume`, and `stop` `suspend` to match what GCD and Cocoa
are doing
- options class to be passed in `init` instead of `start`

gelareh

···

From: Gelareh Taban/Austin/IBM
To: Helge Heß <me@helgehess.eu>
Cc: Helge Heß via swift-server-dev <swift-server-dev@swift.org>
Date: 10/30/2017 04:50 PM
Subject: Re: [swift-server-dev] HTTP API proposal for TLS integration

Good points on the existing design (without TLS). I worked with what was
there, but in general I like the idea of having an options class, which
gets set in `init`. Kind of like what we did with TLSConfiguration.

I can't comment on the parser/writer design and the multi-port, perhaps
@Chris Bailey?

gelareh

From: Helge Heß via swift-server-dev <swift-server-dev@swift.org>
To: Helge Heß via swift-server-dev <swift-server-dev@swift.org>
Date: 10/30/2017 12:06 PM
Subject: Re: [swift-server-dev] HTTP API proposal for TLS integration
Sent by: swift-server-dev-bounces@swift.org

Hi,

a few things I noticed working on it:

- IMO the closure, ports and stuff should go into the `init`.

- The HTTPServing thing I don’t get at all. Why do we need this?
- Kinda the same for HTTPResponseWriter. (it is particularly weird that the
writer is coupled with the parser in this implementation - they should be
completely distinct).

- `start` should maybe be called `resume`, and `stop` `suspend` to match
what GCD and Cocoa are doing.

- If we get tons of options we may rather want to add a

class HTTPServer {
  class Options { // a class because subclasses may want to add
    var certificate : ..
    var port : ...
  }
}

- Other things we need in the options: request/response logging.

- I was also wondering how we would want to handle multiple ports and in
general addresses.
You would at least want to be able to listen on IPv6 …

I can see two options here:
- either create multiple server objects for each sockaddr_in
- or add listeners to the server objects
  - this could be internal, but there needs to API to specify
    what sockaddr_in’s you want to listen on.

hh

On 30. Oct 2017, at 17:41, Gelareh Taban via swift-server-dev <swift-server-dev@swift.org> wrote:

Hi all,

As part of PR#78 for TLS integration into HTTP,

TLS integration by gtaban · Pull Request #78 · swift-server/http · GitHub, I had to update the HTTP API
and would like to ask for feedback.

The TLS code sits in:
GitHub - gadphly/swift_server_security: Repository for the development of cross-platform Security APIs // protocol definitions and data

types

GitHub - gtaban/TLSService: SSL/TLS Add-in for BlueSocket using Secure Transport and OpenSSL // implementation using OpenSSL

on Linux and SecureTransport on macOS

The proposed HTTP API changes are in HTTPServing protocol:

/// Start the HTTP server on the given `port`, using `handler` to process

incoming requests

- func start(port: Int, handler: @escaping HTTPRequestHandler) throws

+ func start(port: Int, tls: TLSConfiguration?, handler: @escaping

HTTPRequestHandler) throws

and HTTPServer class `start()` function:

- public func start(port: Int = 0, handler: @escaping HTTPRequestHandler)

throws {

- try server.start(port: port, handler: handler)

+ public func start(port: Int = 0, tls: TLSConfiguration? = nil, handler:

@escaping HTTPRequestHandler) throws {

+ try server.start(port: port, tlsConfig: tls, handler: handler)

TLSConfiguration is a struct defined in:

which stores TLS parameters that are needed to configure a TLS

connection. These include credentials (certificates and passwords) and
cipher suites.

There is a corresponding change in PoCSocket/PoCSocketSimpleServer.swift

`start()` to pass in the configuration.

The way that the proposed APIs would get uses can be seen in

Tests/HTTPTests/TLSServerTests.swift.

let config = createCASignedTLSConfig()

// HTTP
try server.start(port: 0, handler: simpleHelloWebApp.handle)

// HTTPS
try server.start(port: 0, tls: config, handler: simpleHelloWebApp.handle)

Regards,
Gelareh
_______________________________________________
swift-server-dev mailing list
swift-server-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev

[attachment "signature.asc" deleted by Gelareh Taban/Austin/IBM]
_______________________________________________
swift-server-dev mailing list
swift-server-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev