Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Issue with MAX_COOKIE_HEADER_LEN
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Benjamin Herrenschmidt via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 17 May 2023 14:52:14 +1000
Hi !
This is my first involvement with Curl development, so please bear with
me if I'm missing some established practices here :-) I usually dabble
in kernel land.
We (Amazon Linux distribution) have had customers complaining of their
use cases being broken by commit:
48d7064a49148f03942380967da739dcde1cdc24 cookie: apply limits
And more specifically by the 8KB limit applied to the cookier headers.
Now I understand the value in preventing runaway header attacks and it
does make a lot of sense to use a limit, but is there a reason not to
make this limit configurable for use cases where 8KB is simply not
sufficient ?
I'm happy to send a patch (or github PR) but since I'm not that
familiar with Curl practices, I would like first to discuss here, first
if the idea is acceptable and if it is, what's the best approach.
I'm generally weary of libcurl API/ABI changes, so the least disruptive
approach I can think of would be to have an env. variable that can
optionally raise the limit. The idea here would be to test it if (and
only if) the size is above MAX_COOKIE_HEADER_LEN, in order to avoid
incurring the cost of a getenv() call in the normal case. ie. something
roughly along those lines:
--- a/lib/http.c
+++ b/lib/http.c
_at__at_ -2840,8 +2840,11 _at__at_ CURLcode Curl_http_cookies(struct Curl_easy *data,
if(result)
break;
}
- if((Curl_dyn_len(r) + strlen(co->name) + strlen(co->value) + 1) >=
- MAX_COOKIE_HEADER_LEN) {
+ size = (Curl_dyn_len(r) + strlen(co->name) + strlen(co->value) + 1;
+ if(size) >= MAX_COOKIE_HEADER_LEN) {
+
+ /* XXX do getenv() here and check again (option: cache the result) */
+
infof(data, "Restricted outgoing cookies due to header size, "
"'%s' not sent", co->name);
linecap = TRUE;
Alternatively, but that's an API/ABI change of libcurl, add a new
option (via curl_easy_setopt) to specify the limit (and possibly while
at it to also specify the other limits added by the above commit). This
would have to go alongside a change to the curl client program to be
able to specify these limits.
Cheers,
Ben.
Date: Wed, 17 May 2023 14:52:14 +1000
Hi !
This is my first involvement with Curl development, so please bear with
me if I'm missing some established practices here :-) I usually dabble
in kernel land.
We (Amazon Linux distribution) have had customers complaining of their
use cases being broken by commit:
48d7064a49148f03942380967da739dcde1cdc24 cookie: apply limits
And more specifically by the 8KB limit applied to the cookier headers.
Now I understand the value in preventing runaway header attacks and it
does make a lot of sense to use a limit, but is there a reason not to
make this limit configurable for use cases where 8KB is simply not
sufficient ?
I'm happy to send a patch (or github PR) but since I'm not that
familiar with Curl practices, I would like first to discuss here, first
if the idea is acceptable and if it is, what's the best approach.
I'm generally weary of libcurl API/ABI changes, so the least disruptive
approach I can think of would be to have an env. variable that can
optionally raise the limit. The idea here would be to test it if (and
only if) the size is above MAX_COOKIE_HEADER_LEN, in order to avoid
incurring the cost of a getenv() call in the normal case. ie. something
roughly along those lines:
--- a/lib/http.c
+++ b/lib/http.c
_at__at_ -2840,8 +2840,11 _at__at_ CURLcode Curl_http_cookies(struct Curl_easy *data,
if(result)
break;
}
- if((Curl_dyn_len(r) + strlen(co->name) + strlen(co->value) + 1) >=
- MAX_COOKIE_HEADER_LEN) {
+ size = (Curl_dyn_len(r) + strlen(co->name) + strlen(co->value) + 1;
+ if(size) >= MAX_COOKIE_HEADER_LEN) {
+
+ /* XXX do getenv() here and check again (option: cache the result) */
+
infof(data, "Restricted outgoing cookies due to header size, "
"'%s' not sent", co->name);
linecap = TRUE;
Alternatively, but that's an API/ABI change of libcurl, add a new
option (via curl_easy_setopt) to specify the limit (and possibly while
at it to also specify the other limits added by the above commit). This
would have to go alongside a change to the curl client program to be
able to specify these limits.
Cheers,
Ben.
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-05-17