Not sure if I'm right about this. I have a Mac command line target that's starting a Hummingbird server.

What appears to be happening is that if the port I ask it to start on is already taken, Hummingbird fail and hangs at this point:

This doesn't seem to occur when running the same startup code on an iOS simulator, just when running via a Mac command.

Any clues how I might resolve this?

Within the context of middleware, the request's endpointPath property will always be nil. This is due to the endpointPath being set by the TrieRouter after all middleware was applied, as shown in the following call tree:

In this call tree "0" refers to the following line:

https://github.com/hummingbird-project/hummingbird/blob/434fdd8d96e1ac2661c1150aefa95e127f2d942f/Sources/Hummingbird/Router/TrieRouter.swift#L53

I also checked the built-in HBMetricsMiddleware and it resulted in the same lack of an endpointPath while it was being applied. For Distributed Tracing support however the endpoint path is more or less required since it should be used as the span name.

Hi, I just updated to 0.16.2 and I'm getting a compilation error on lines 32 & 38 of HBLogRequestsMiddleware where it's attempting to log request.uri:

if self.includeHeaders {
    request.logger.log(
        level: self.logLevel,
        "\(request.headers)",
        metadata: ["hb_uri": .stringConvertible(request.uri), "hb_method": .string(request.method.rawValue)] <-- Error!
    )
} else {
    request.logger.log(
        level: self.logLevel,
        "",
        metadata: ["hb_uri": .stringConvertible(request.uri), "hb_method": .string(request.method.rawValue)] <-- Error!
    )
}

Not sure why this is coming up now as it hasn't changed for some time and neither has the code in .stringConvertable(...).

Made HBRequest and HBResponse structs. This should make moving to a full async/await implementation a little easier as they become automatically Sendable as long as all their members are Sendable.

For most situations, code changes related to HBResponse becoming a struct involves making a mutable instance of the response.

It is slightly more complex for HBRequest. HBRequest is large enough such that converting it to a struct actually reduces performance. To fix this I have moved all the parameters of HBRequest that are read only into an internal class. There is no point copying all this data through all the response generators. Storing it in a class means only a reference to the data is passed through.

Having HBRequest as a struct also means some APIs that would have edited the request have had to change. You can see this in changes to hummingbird-auth

Hi, I've setup my server to look at the request.body as a ByteBuffer to get the contents of the incoming request. However I'm receiving an unexpected request from the app (not under my control) that is returning a stream instead of a byte buffer. I'm trying to figure out how to read this stream and have been digging through the Hummingbird code base to try and figure it out but not having much luck so far.

For byte buffers I've been doing

let buffer = request.body.buffer
let data = buffer.getData(at: 0, length: buffer.readableBytes)

But this crashes when the body is set to a stream.

Any ides how to read the data?

In my server applications I usually have two servers running, one for the public API of a service and one for the admin API (e.g. to expose a /metrics route), but I still want them to run in the same process/container. I'd like to be able to use ServiceLifecycle to pull them all together but that's currently not possible since HBApplication creates its own top-level lifecycle. If we were to use ComponentLifecycle instead, an HBApplication and all its lifecycle tasks could be registered as a subcomponent of a larger lifecycle, which could look like this:

let lifecycle = ServiceLifecycle()

let eventLoopGroup = MultiThreadedEventLoopGroup(numberOfThreads: System.coreCount)
lifecycle.registerShutdown(label: "event-loop-group", .async(eventLoopGroup.shutdownGracefully))

let publicApp = HBApplication(
    configuration: .init(
        address: .hostname(options.host, port: Int(options.publicPort)),
        serverName: "Example API",
        logLevel: options.logLevel
    ),
    eventLoopGroupProvider: .shared(eventLoopGroup)
)
lifecycle.register(publicApp.lifecycle)

let adminApp = HBApplication(
    configuration: .init(
        address: .hostname(options.host, port: Int(options.adminPort)),
        serverName: "Example API [Admin]",
        logLevel: options.logLevel
    ),
    eventLoopGroupProvider: .shared(eventLoopGroup)
)
lifecycle.register(adminApp.lifecycle)

try lifecycle.startAndWait()

As promised, this is the second PR. It introduces the ability to handle a HBHTTPResponseError and provide a custom response, falling back to the default implementation in HTTPResponder using HBHTTPResponseError if the errorResponseHandler is not provided.

The reason for this PR is that I wanted to continue using standard HBHTTPErrors e.g. HBHTTPError(.notFound) at the higher-levels of the application, but have the ability to create/manipulate a custom response in-place of the ones provided by HBHTTPResponseError itself at a global level.

Trying to add Hummingbird to a project but I'm getting errors compiling swift-service-lifecycle. It appears that classes in there use Task which is iOS13 and above, whilst Hummingbird's package indicates it's minimum version as iOS12 and regardless of the iOS version I set on the project, it won't compile.

Any idea how to fix this?

See comment below for more info from a package project I was trying to use. Have since also tried in a single screen iOS app and got the same compilation error.

Just came across some API calls here with repeating query parameters. Things like ...?category=cars&category=engines (a bit contrived but still possible). I looked in the code for HBParameters and it's coded like I would have done it in that it's baed on a dictionary. But with this new information it needs to be able to handle repeating keys with different values. So I'm thinking more like an array of tuples or some simple struct type.

Pursuant to the discussion in https://github.com/hummingbird-project/hummingbird/issues/132 I messed about to see if I could come up with something that would allow the future to resolve and the current thread to release.

The NIO API doco actually suggests that using .wait() might not be a good idea so I decided to try replacing the promise/future with run loop execution. It worked, allowing the .start() function to throw an error if the port was not available both iOS and OSX.

However, I'm not an expert in the the NIO code or all the depths of multithreading at that level so whilst this solutions works, it may not be the best one.

All tests were run and green with this code.

I was trying to load files from a bundle of files passed to a test suite. In my server setup I had this middleware:

let configuration = HBApplication.Configuration()
let server = HBApplication(configuration: configuration)
server.middleware.add(HBFileMiddleware(Bundle.testData.filePath.absoluteString, application: server))
try server.start()

However whenever I requested a file from the testData bundle HBFileMiddleware failed to find it.

I debugged through and found that the string based root folder was being set to a file:///... path which was not understood by the file code attempting to load the file.

This PR:

• Converts rootFolder to be a file URL instead of a string.
• Updates usage of rootFolder based on it now being a URL. ie. rootFolder.relativePath.
• Removes checking for a trailing / which is no longer needed.

Testing

After the code change all Hummingbird test ran green without change.