Trouble when Hummingbird 2.0.1 used with an Nginx proxy.

[dkyowell]

I have been converting some internal projects from Vapor to Hummingbird. I have run into an issue when using Hummingbird as the protected server behind an Nginx reverse proxy. My Hummingbird based server generates PDF content dynamically. It works perfectly when accessed directly by clients on the LAN. It works across the Nginx proxy when the PDF is very small. When the PDF is larger, I get the following error in my iOS client using URLSession. (It also fails to load from Postman when used with the proxy). The exact same client setup and Nginx reverse proxy worked fine when using Vapor.

Task <8A55EAB5-D2A9-4D3C-A478-F107C107C304>.<29> failed strict content length check - expected: 283409, received: 131629, received (uncompressed): 0

Any thoughts on what could be causing this?

[adam-fowler]

This is most likely a known bug in SwiftNIO where the connection is closed before the whole of the payload is written.

At this point your best bet for getting around this is using a keep-alive connection and then running a separate dummy request on the same connection with header connection: close which expects no payload to close the connection. I know this is not great, but until SwiftNIO fix this there isn't much I can do.

[dkyowell]

Thanks for your response. My understanding is that HTTP 1.1 is keep-alive by default. When I run this request from Postman, I can see that keep-alive is already set in the request header (and confirmed in the response header), but it still receives the truncated data.

I did not mention that this particular Hummingbird host is run from MacOS Sequoia. I am also running a similar configuration from a Linux host / Nginx reverse proxy and do not have any trouble with that.

[adam-fowler]

I can see that keep-alive is already set in the request header (and confirmed in the response header), but it still receives the truncated data.

I'm not certain why the connection is being closed but I'm pretty sure Hummingbird has sent all the writes. It is most likely the issue I mentioned above where NIO isn't flushing all its writes before closing the connection. I will go hassle them to fix this. I know they have already been discussing solutions.

[dkyowell]

Thanks!

[adam-fowler]

I'd like to keep this open, then I can tell you when the issue is resolved.

[adam-fowler]

Actually can you create an Issue for this as it would be a better way to track it.

Cheers

[dkyowell]

I created the issue per your request. This morning, I created a fresh Nginx proxy just to rule out that I did not have an unusual proxy configuration that was causing the issue...my old proxy installation was 6 years old. No luck; same result with a fresh proxy install.

[adam-fowler]

Thank you