- Quickstart
- Features
- Access Control
- Access Logging
- Authorization
- BGP
- Certificate Stores
- Docker Support
- Dynamic Reloading
- Graceful Shutdown
- GRPC Proxy
- HTTP Compression
- HTTP Header Support
- HTTP Path Prepending
- HTTP Path Stripping
- HTTP Redirects
- HTTPS TCP-SNI Proxy
- HTTPS Upstream
- Metrics
- PROXY Protocol Support
- Server Sent Events (SSE)
- TCP Dynamic Proxy
- TCP Proxy
- TCP-SNI Proxy
- Traffic Shaping
- Vault Support
- Web UI
- Websockets
- Deployment
- Config Language
- Reference
- FAQ
- Contributing
- Code of Conduct
- Contact
Websockets
fabio transparently supports Websocket connections by detecting theUpgrade: websocket
header in the incoming HTTP(S) request.
Websocket support has been implemented with the websocket library fromgolang.org/x/net/websocket.
You can test the websocket support with thedemo/wsclient
anddemo/server
whichimplements a simple echo server.
./server -addr 127.0.0.1:5000 -name ws-a -prefix /echo -proto ws./wsclient -url ws://127.0.0.1:9999/echo
You can also run multiple web socket servers on different ports but the same endpoint.
fabio detects on whether to forward the request as HTTP or WS based on thevalue of theUpgrade
header. If the value iswebsocket
it will attempt awebsocket connection to the target. Otherwise, it will fall back to HTTP.
One limitation of the current implementation is that the accepted set ofprotocols has to be symmetric across all services handling it. Only thefollowing combinations will work reliably:
svc-a and svc-b register /foo and accept only HTTP traffic theresvc-a and svc-b register /foo and accept only WS traffic theresvc-a and svc-b register /foo and accept both HTTP and WS traffic there
The following setup (or variations thereof) will not work reliably:
svc-a registers /foo and accept only WS traffic theresvc-b registers /foo and accept only HTTP traffic there
This is not a limitation of the routing itself but because the currentconfiguration does not provide fabio with enough information to make therouting decision since the services do not advertise the protocols they handleon a given endpoint.
This does not look like a big restriction but is also not difficult to extendin a later version assuming there are use cases which require this behavior.For now the services have to be symmetric in the protocols they accept.