Bump to v1.0.5

Fixes #9: Support websockets
Fixes #10: Support Forwarded and X-Forwarded-For headers

CHANGELOG.md

@@ -1,13 +1,14 @@
 ## Changelog
 
-### WIP
+### [v1.0.5](https://github.com/eBay/fabio/releases/tag/v1.0.5) - 11 Nov 2015
 
- * Add support for `Forwarded` and `X-Forwarded-For` header
+ * [Issue #9](https://github.com/eBay/fabio/issues/9): Add experimental support for web sockets
+ * [Issue #10](https://github.com/eBay/fabio/issues/10): Add support for `Forwarded` and `X-Forwarded-For` header
  * Add `proxy.localip` to set proxy ip address for headers
 
 ### [v1.0.4](https://github.com/eBay/fabio/releases/tag/v1.0.4) - 03 Nov 2015
 
- * Add support for SSL client certificate authentication
+ * [Issue #8](https://github.com/eBay/fabio/issues/8): Add support for SSL client certificate authentication
 
 ### [v1.0.3](https://github.com/eBay/fabio/releases/tag/v1.0.3) - 25 Oct 2015
 

README.md

@@ -1,6 +1,6 @@
 # ./fabio [![Build Status](https://travis-ci.org/eBay/fabio.svg?branch=master)](https://travis-ci.org/eBay/fabio)
 
-##### Current version: 1.0.4
+##### Current version: 1.0.5
 
 fabio is a fast, modern, zero-conf load balancing HTTP(S) router
 for deploying microservices managed by consul.
@@ -47,11 +47,13 @@ several fabio instances. We don't observe any measurable additional latency.
 * Hot-reloading of routing table through backend watchers
 * Round robin and random distribution
 * [Traffic Shaping](#traffic-shaping) (send 5% of traffic to new instances)
-* SSL client certificate authentication support (see `proxy.addr` in [fabio.properties](https://raw.githubusercontent.com/eBay/fabio/master/fabio.properties))
 * Graphite metrics
 * Request tracing
 * WebUI
 * Fast
+* v1.0.4: SSL client certificate authentication support (see `proxy.addr` in [fabio.properties](https://raw.githubusercontent.com/eBay/fabio/master/fabio.properties))
+* v1.0.5: `X-Forwarded-For` and `Forwarded` header support
+* v1.0.5: Websocket support (experimental)
 
 ## Documentation
 
@@ -64,6 +66,7 @@ several fabio instances. We don't observe any measurable additional latency.
 * [Manual overrides](#manual-overrides)
 * [Routing](#routing)
 * [Traffic shaping](#traffic-shaping)
+* [Websockets](#websockets)
 * [Debugging](#debugging)
 * [Request tracing](#request-tracing)
 * [Web UI](#web-ui)
@@ -345,6 +348,48 @@ publishing the same prefix.
 route weight service-b www.kjca.dev/auth/ weight 0.05 tags "version-15,dc-fra"
 ```
 
+## Websockets
+
+Websocket support works but is considered experimental since I don't have an
+in-house use case for it at the moment. I would like to hear from users whether it
+works in their environments beyond my simple test case before I declare it stable.
+It has been implemented with the websocket library from
+[golang.org/x/net/websocket](http://golang.org/x/net/websocket)
+
+You can test the websocket support with the `demo/wsclient` and `demo/server` which
+implements 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 the
+value of the `Upgrade` header. If the value is `websocket` it will attempt a
+websocket connection to the target. Otherwise, it will fall back to HTTP.
+
+One limitation of the current implementation is that the accepted set of
+protocols has to be symmetric across all services handling it. Only the
+following combinations will work reliably:
+
+    svc-a and svc-b register /foo and accept only HTTP traffic there
+    svc-a and svc-b register /foo and accept only WS traffic there
+    svc-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 there
+    svc-b registers /foo and accept only HTTP traffic there
+
+This is not a limitation of the routing itself but because the current
+configuration does not provide fabio with enough information to make the
+routing decision since the services do not advertise the protocols they handle
+on a given endpoint.
+
+This does not look like a big restriction but is also not difficult to extend
+in 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.
+
 ## Debugging
 
 To send a request from the command line via the fabio using `curl`