DOC: minor updates to the proxy protocol doc

Update the release data, revision history and the link to the Forwarded
HTTP extension.

diff --git a/doc/proxy-protocol.txt b/doc/proxy-protocol.txt
index b0ec08b080c6f653c518aafacf644f9370e5d961..a2dbceaf5d34fd3074e8340f8e1c8f97a042f2d0 100644 (file)
--- a/doc/proxy-protocol.txt
+++ b/doc/proxy-protocol.txt
@@ -1,4 +1,4 @@
-2014/05/10                                                        Willy Tarreau
+2014/06/14                                                        Willy Tarreau
                                                            HAProxy Technologies
                                The PROXY protocol
                                  Versions 1 & 2
@@ -19,6 +19,8 @@ Revision history
    2012/06/21 - add support for binary format
    2012/11/19 - final review and fixes
    2014/05/18 - modify and extend PROXY protocol version 2
+   2014/06/11 - fix example code to consider ver+cmd merge
+   2014/06/14 - fix v2 header check in example code, and update Forwarded spec
 
 
 1. Background
@@ -27,11 +29,11 @@ Relaying TCP connections through proxies generally involves a loss of the
 original TCP connection parameters such as source and destination addresses,
 ports, and so on. Some protocols make it a little bit easier to transfer such
 information. For SMTP, Postfix authors have proposed the XCLIENT protocol [1]
-which received broad adoption and is particularly suited to mail exchanges. In
-HTTP, there is the "Forwarded-For" proposed standard [2]. This proposal aims at
-replacing the omnipresent "X-Forwarded-For" header which carries information
-about the original source address, and the less common X-Original-To which
-carries information about the destination address.
+which received broad adoption and is particularly suited to mail exchanges.
+For HTTP, there is the "Forwarded" extension [2], which aims at replacing the
+omnipresent "X-Forwarded-For" header which carries information about the
+original source address, and the less common X-Original-To which carries
+information about the destination address.
 
 However, both mechanisms require a knowledge of the underlying protocol to be
 implemented in intermediaries.
@@ -40,10 +42,11 @@ Then comes a new class of products which we'll call "dumb proxies", not because
 they don't do anything, but because they're processing protocol-agnostic data.
 Both Stunnel[3] and Stud[4] are examples of such "dumb proxies". They talk raw
 TCP on one side, and raw SSL on the other one, and do that reliably, without
-any knowledge of what protocol is transported on top of the connection.
+any knowledge of what protocol is transported on top of the connection. Haproxy
+running in pure TCP mode obviously falls into that category as well.
 
 The problem with such a proxy when it is combined with another one such as
-haproxy is to adapt it to talk the higher level protocol. A patch is available
+haproxy, is to adapt it to talk the higher level protocol. A patch is available
 for Stunnel to make it capable of inserting an X-Forwarded-For header in the
 first HTTP request of each incoming connection. Haproxy is able not to add
 another one when the connection comes from Stunnel, so that it's possible to
@@ -734,7 +737,7 @@ Please use w@1wt.eu to send any comments to the author.
 The following links were referenced in the document.
 
 [1] http://www.postfix.org/XCLIENT_README.html
-[2] http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded
+[2] http://tools.ietf.org/html/rfc7239
 [3] http://www.stunnel.org/
 [4] https://github.com/bumptech/stud
 [5] https://github.com/bumptech/stud/pull/81