DOC: update RFC references

A few doc and code comment updates bumping RFC references to the new
ones.

doc/configuration.txt

@@ -268,7 +268,7 @@ about the way they could be written, but it is important not to accuse an
 application of being buggy if it does unusual, valid things.
 
 Important note:
-   As suggested by RFC2616, HAProxy normalizes headers by replacing line breaks
+   As suggested by RFC7231, HAProxy normalizes headers by replacing line breaks
    in the middle of headers by LWS in order to join multi-line headers. This
    is necessary for proper analysis and helps less capable HTTP parsers to work
    correctly and not to be fooled by such complex constructs.
@@ -318,7 +318,7 @@ The status code is always 3-digit. The first digit indicates a general status :
  - 4xx = error caused by the client (eg: 401, 403, 404)
  - 5xx = error caused by the server (eg: 500, 502, 503)
 
-Please refer to RFC2616 for the detailed meaning of all such codes. The
+Please refer to RFC7231 for the detailed meaning of all such codes. The
 "reason" field is just a hint, but is not parsed by clients. Anything can be
 found there, but it's a common practice to respect the well-established
 messages. It can be composed of one or multiple words, such as "OK", "Found",
@@ -2319,7 +2319,7 @@ balance url_param <param> [check_post]
     - Expect: 100-continue is not supported, load balancing will fall back to
       Round Robin.
 
-    - Transfer-Encoding (RFC2616 3.6.1) is only supported in the first chunk.
+    - Transfer-Encoding (RFC7230 3.3.1) is only supported in the first chunk.
       If the entire parameter value is not present in the first chunk, the
       selection of server is undefined (actually, defined by how little
       actually appeared in the first chunk).
@@ -5648,7 +5648,7 @@ no option http-server-close
   latency on the client side (slow network) and the fastest session reuse on
   the server side to save server resources, similarly to "option forceclose".
   It also permits non-keepalive capable servers to be served in keep-alive mode
-  to the clients if they conform to the requirements of RFC2616. Please note
+  to the clients if they conform to the requirements of RFC7230. Please note
   that some servers do not always conform to those requirements when they see
   "Connection: close" in the request. The effect will be that keep-alive will
   never be used. A workaround consists in enabling "option
@@ -5715,7 +5715,7 @@ no option http-use-proxy-header
                                  yes   |    yes   |   yes  |   no
   Arguments : none
 
-  While RFC2616 explicitly states that HTTP/1.1 agents must use the
+  While RFC7230 explicitly states that HTTP/1.1 agents must use the
   Connection header to indicate their wish of persistent or non-persistent
   connections, both browsers and proxies ignore this header for proxied
   connections and make use of the undocumented, non-standard Proxy-Connection
@@ -14598,7 +14598,7 @@ req.hdr([<name>[,<occ>]]) : string
   with -1 being the last one. A typical use is with the X-Forwarded-For header
   once converted to IP, associated with an IP stick-table. The function
   considers any comma as a delimiter for distinct values. If full-line headers
-  are desired instead, use req.fhdr(). Please carefully check RFC2616 to know
+  are desired instead, use req.fhdr(). Please carefully check RFC7231 to know
   how certain headers are supposed to be parsed. Also, some of them are case
   insensitive (eg: Connection).
 

include/common/defaults.h

@@ -136,7 +136,7 @@
 #endif
 
 // cookie delimitor in "prefix" mode. This character is inserted between the
-// persistence cookie and the original value. The '~' is allowed by RFC2965,
+// persistence cookie and the original value. The '~' is allowed by RFC6265,
 // and should not be too common in server names.
 #ifndef COOKIE_DELIM
 #define COOKIE_DELIM    '~'

include/proto/proto_http.h

@@ -30,7 +30,7 @@
 
 /*
  * some macros used for the request parsing.
- * from RFC2616:
+ * from RFC7230:
  *   CTL                 = <any US-ASCII control character (octets 0 - 31) and DEL (127)>
  *   SEP                 = one of the 17 defined separators or SP or HT
  *   LWS                 = CR, LF, SP or HT

include/types/proto_http.h

@@ -171,7 +171,7 @@ enum ht_state {
 	 */
 	HTTP_MSG_BODY         = 27, // parsing body at end of headers
 	HTTP_MSG_100_SENT     = 28, // parsing body after a 100-Continue was sent
-	HTTP_MSG_CHUNK_SIZE   = 29, // parsing the chunk size (RFC2616 #3.6.1)
+	HTTP_MSG_CHUNK_SIZE   = 29, // parsing the chunk size (RFC7230 #4.1)
 	HTTP_MSG_DATA         = 30, // skipping data chunk / content-length data
 	HTTP_MSG_CHUNK_CRLF   = 31, // skipping CRLF after data chunk
 	HTTP_MSG_TRAILERS     = 32, // trailers (post-data entity headers)
@@ -274,7 +274,7 @@ enum {
 	STAT_STATUS_SIZE
 };
 
-/* This is an HTTP message, as described in RFC2616. It can be either a request
+/* This is an HTTP message, as described in RFC7230. It can be either a request
  * message or a response message.
  *
  * The values there are a little bit obscure, because their meaning can change

src/haproxy.c

@@ -7,8 +7,8 @@
  * as published by the Free Software Foundation; either version
  * 2 of the License, or (at your option) any later version.
  *
- * Please refer to RFC2068 or RFC2616 for informations about HTTP protocol, and
- * RFC2965 for informations about cookies usage. More generally, the IETF HTTP
+ * Please refer to RFC7230 - RFC7235 informations about HTTP protocol, and
+ * RFC6265 for informations about cookies usage. More generally, the IETF HTTP
  * Working Group's web site should be consulted for protocol related changes :
  *
  *     http://ftp.ics.uci.edu/pub/ietf/http/

src/proto_http.c

@@ -850,8 +850,8 @@ int http_find_next_header(char *sol, struct hdr_idx *idx, struct hdr_ctx *ctx)
 	return 0;
 }
 
-/* Find the end of the header value contained between <s> and <e>. See RFC2616,
- * par 2.2 for more information. Note that it requires a valid header to return
+/* Find the end of the header value contained between <s> and <e>. See RFC7230,
+ * par 3.2 for more information. Note that it requires a valid header to return
  * a valid result. This works for headers defined as comma-separated lists.
  */
 char *find_hdr_value_end(char *s, const char *e)
@@ -1119,7 +1119,7 @@ char *http_get_path(struct http_txn *txn)
 	if (ptr >= end)
 		return NULL;
 
-	/* RFC2616, par. 5.1.2 :
+	/* RFC7230, par. 2.7 :
 	 * Request-URI = "*" | absuri | abspath | authority
 	 */