---
A few doc and code comment updates bumping RFC references to the new
ones.
---
doc/configuration.txt | 12 ++++++------
include/common/defaults.h | 2 +-
include/proto/proto_http.h | 2 +-
include/types/proto_http.h | 4 ++--
src/haproxy.c | 4 ++--
src/proto_http.c | 6 +++---
6 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/doc/configuration.txt b/doc/configuration.txt
index bfce6b1..06a1a2a 100644
--- a/doc/configuration.txt
+++ b/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).
diff --git a/include/common/defaults.h b/include/common/defaults.h
index 1618ab4..81dc3b1 100644
--- a/include/common/defaults.h
+++ b/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 '~'
diff --git a/include/proto/proto_http.h b/include/proto/proto_http.h
index 9409df3..14c0ce6 100644
--- a/include/proto/proto_http.h
+++ b/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
diff --git a/include/types/proto_http.h b/include/types/proto_http.h
index 9987c33..1d378ac 100644
--- a/include/types/proto_http.h
+++ b/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
diff --git a/src/haproxy.c b/src/haproxy.c
index 02f90a8..261b213 100644
--- a/src/haproxy.c
+++ b/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/
diff --git a/src/proto_http.c b/src/proto_http.c
index 579473b..53bfd8b 100644
--- a/src/proto_http.c
+++ b/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
*/
--
2.7.4
