MEDIUM: http: wait for the first chunk or message body length in http_process_body
This is the continuation of previous patch. Now that full buffers are
not rejected anymore, let's wait for at least the advertised chunk or
body length to be present or the buffer to be full. When either
condition is met, the message processing can go forward.
Thus we don't need to use url_param_post_limit anymore, which was passed
in the configuration as an optionnal <max_wait> parameter after the
"check_post" value. This setting was necessary when the feature was
implemented because there was no support for parsing message bodies.
The argument is now silently ignored if set in the configuration.
diff --git a/doc/configuration.txt b/doc/configuration.txt
index 65df417..76b093e 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -1504,7 +1504,7 @@
balance <algorithm> [ <arguments> ]
-balance url_param <param> [check_post [<max_wait>]]
+balance url_param <param> [check_post]
Define the load balancing algorithm to be used in a backend.
May be used in sections : defaults | frontend | listen | backend
yes | no | yes | yes
@@ -1609,23 +1609,13 @@
If the modifier "check_post" is used, then an HTTP POST
request entity will be searched for the parameter argument,
when it is not found in a query string after a question mark
- ('?') in the URL. Optionally, specify a number of octets to
- wait for before attempting to search the message body. If the
- entity can not be searched, then round robin is used for each
- request. For instance, if your clients always send the LB
- parameter in the first 128 bytes, then specify that. The
- default is 48. The entity data will not be scanned until the
- required number of octets have arrived at the gateway, this
- is the minimum of: (default/max_wait, Content-Length or first
- chunk length). If Content-Length is missing or zero, it does
- not need to wait for more data than the client promised to
- send. When Content-Length is present and larger than
- <max_wait>, then waiting is limited to <max_wait> and it is
- assumed that this will be enough data to search for the
- presence of the parameter. In the unlikely event that
- Transfer-Encoding: chunked is used, only the first chunk is
+ ('?') in the URL. The message body will only start to be
+ analyzed once either the advertised amount of data has been
+ received or the request buffer is full. In the unlikely event
+ that chunked encoding is used, only the first chunk is
scanned. Parameter values separated by a chunk boundary, may
- be randomly balanced if at all.
+ be randomly balanced if at all. This keyword used to support
+ an optional <max_wait> parameter which is now ignored.
If the parameter is found followed by an equal sign ('=') and
a value, then the value is hashed and divided by the total
@@ -1682,9 +1672,6 @@
algorithms. Right now, only "url_param" and "uri" support an
optional argument.
- balance uri [len <len>] [depth <depth>]
- balance url_param <param> [check_post [<max_wait>]]
-
The load balancing algorithm of a backend is set to roundrobin when no other
algorithm, mode nor option have been set. The algorithm may only be set once
for each backend.
diff --git a/include/types/proxy.h b/include/types/proxy.h
index dc75f63..28be984 100644
--- a/include/types/proxy.h
+++ b/include/types/proxy.h
@@ -256,7 +256,6 @@
int rdp_cookie_len; /* strlen(rdp_cookie_name), computed only once */
char *url_param_name; /* name of the URL parameter used for hashing */
int url_param_len; /* strlen(url_param_name), computed only once */
- unsigned url_param_post_limit; /* if checking POST body for URI parameter, max body to wait for */
int uri_len_limit; /* character limit for uri balancing algorithm */
int uri_dirs_depth1; /* directories+1 (slashes) limit for uri balancing algorithm */
int uri_whole; /* if != 0, calculates the hash from the whole uri. Still honors the len_limit and dirs_depth1 */
diff --git a/src/backend.c b/src/backend.c
index d878028..72c12d1 100644
--- a/src/backend.c
+++ b/src/backend.c
@@ -1382,15 +1382,6 @@
memprintf(err, "%s only accepts 'check_post' modifier (got '%s').", args[0], args[2]);
return -1;
}
- if (*args[3]) {
- /* TODO: maybe issue a warning if there is no value, no digits or too long */
- curproxy->url_param_post_limit = str2ui(args[3]);
- }
- /* if no limit, or faul value in args[3], then default to a moderate wordlen */
- if (!curproxy->url_param_post_limit)
- curproxy->url_param_post_limit = 48;
- else if ( curproxy->url_param_post_limit < 3 )
- curproxy->url_param_post_limit = 3; /* minimum example: S=3 or \r\nS=6& */
}
}
else if (!strncmp(args[0], "hdr(", 4)) {
diff --git a/src/proto_http.c b/src/proto_http.c
index 51f97aa..ccc3ff2 100644
--- a/src/proto_http.c
+++ b/src/proto_http.c
@@ -4176,7 +4176,6 @@
*/
if (!(s->flags & (SN_ASSIGNED|SN_DIRECT)) &&
s->txn.meth == HTTP_METH_POST && s->be->url_param_name != NULL &&
- s->be->url_param_post_limit != 0 &&
(msg->flags & (HTTP_MSGF_CNT_LEN|HTTP_MSGF_TE_CHNK))) {
channel_dont_connect(req);
req->analysers |= AN_REQ_HTTP_BODY;
@@ -4289,7 +4288,6 @@
{
struct http_txn *txn = &s->txn;
struct http_msg *msg = &s->txn.req;
- long long limit = s->be->url_param_post_limit;
/* We have to parse the HTTP request body to find any required data.
* "balance url_param check_post" should have been the only way to get
@@ -4347,13 +4345,9 @@
/* Now we're in HTTP_MSG_DATA or HTTP_MSG_TRAILERS state.
* We have the first data byte is in msg->sov. We're waiting for at
- * least <url_param_post_limit> bytes after msg->sov.
+ * least a whole chunk or the whole content length bytes after msg->sov.
*/
-
- if (msg->body_len < limit)
- limit = msg->body_len;
-
- if (req->buf->i - msg->sov >= limit) /* we have enough bytes now */
+ if (req->buf->i - msg->sov >= msg->body_len) /* we have enough bytes now */
goto http_end;
missing_data: