Git Product home page Git Product logo

hummingbird-websocket's Introduction

Hummingbird Websocket

Adds support for upgrading HTTP1 connections to WebSocket.

Usage

Setup WebSocket upgrades with a closure that either returns .upgrade with response headers and the handler for the WebSocket or a .dontUpgrade

let app = Application(
    router: router,
    server: .http1WebSocketUpgrade { request, channel, logger in
        // upgrade if request URI is "/ws"
        guard request.uri == "/ws" else { return .dontUpgrade }
        // The upgrade response includes the headers to include in the response and 
        // the WebSocket handler
        return .upgrade([:]) { inbound, outbound, context in
            for try await packet in inbound {
                // send "Received" for every packet we receive
                try await outbound.write(.text("Received"))
            }
        }
    }
)
app.runService()

Or alternatively use a Router. Using a router means you can add middleware to process the initial upgrade request before it is handled eg for authenticating the request.

let wsRouter = Router(context: BasicWebSocketRequestContext.self)
wsRouter.middlewares.add(BasicAuthenticator())
// An upgrade only occurs if a WebSocket path is matched
wsRouter.ws("/ws") { request, context in
    // allow upgrade
    .upgrade()
} onUpgrade: { inbound, outbound, context in
    for try await packet in inbound {
        // send "Received" for every packet we receive
        try await outbound.write(.text("Received"))
    }
}
let app = Application(
    router: router,
    server: .http1WebSocketUpgrade(webSocketRouter: wsRouter)
)
app.runService()

Documentation

You can find documentation for HummingbirdWebSocket here. The hummingbird-examples repository has a number of examples of different uses of the library.

hummingbird-websocket's People

Contributors

adam-fowler avatar hummingbird-automation[bot] avatar joannis avatar tkrajacic avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

hummingbird-websocket's Issues

RFC 6455(?)

Hey,

Longtime user of the hummingbird tools here - really appreciate the work and commitment you've given to building this out. Really good stuff. I've used the HTTP server on Linux for many many many months - and was excited to reach for this hummingbird-websocket project for a new iOS app I'm writing.

Unfortunately, I've found that in the particular framework doesn't work so well with a lot of the "production" web sockets I'm finding in the wild (in this case, I'm writing a nostr websocket client, similar to Damus)

Under my own tight deadlines, and having no firsthand knowledge of the standards behind WebSockets (in the moment), I forked this project and brute forced a problem solving session with GPT-4. Together with this tool, I was able to identify two key ways that this framework is failing in practice.

  • On the RFC side, there seems to be some HTTP headers that are not in your current release that certain server sockets expect to see in the "initial request" in order to proceed with an upgrade.

  • On the HTTP side, I found a subset of servers are responding with an HTTP redirect code, and the framework is not handling that right now (neither throwing an informative error, nor can it be configured to handle a redirect internally).

The fork I'm currently developing is here, it's scrappy and not as good looking as the code you write.

For now, just wanted to share the issue and the existence of my fork, which is working better (but not yet perfect) for my particular needs. Pending any possible guidance or feedback from you, I'll open a PR in the next week or two and see if we cant get these changes polished up and merged (if you have an interest in pursuing).

Add timeout when closing a WebSocket connection

The server MUST close the underlying TCP
connection immediately; the client SHOULD wait for the server to
close the connection but MAY close the connection at any time after
sending and receiving a Close message, e.g., if it has not received a
TCP Close from the server in a reasonable time period.

I think we're currently not closing the connection at all if a server keeps it open.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.