Buy commercial curl support. 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 Daniel himself.
Re: Limit the URL size more?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Dimitry Andric via curl-library <curl-library_at_lists.haxx.se>
Date: Mon, 15 Dec 2025 01:46:24 +0100
On 15 Dec 2025, at 00:33, Daniel Stenberg <daniel_at_haxx.se> wrote:
>
> On Sun, 14 Dec 2025, Dimitry Andric via curl-library wrote:
>
>> Obviously, there is a limit to how large an MP4 you can send with it, and for anything larger you must use POST or PUT, but there is still something to be said for being able to choose a limit (preferably at run time) that makes sense for your particular use case.
>
> It seems rather ineffective to base64 it just to be able to put it in the URL!
>
> I really want us to avoid adding an option for this. We already have too many options. We need docs, tests and more to maintain every option and every option adds to the haystack in which users needs to find their needles when they look for specific options.
Yeah, that is perfectly understandable. The default now is probably a bit high, it makes sense to lower it.
>> E.g., we usually also configured Apache with "LimitRequestLine 100000000",
>
> Wow.
I looked it up, the actual default is 8190 (probably to account for the \r\n):
https://github.com/apache/httpd/blob/trunk/include/httpd.h#L195
Nginx also uses 8k, the directive there is 'large_client_header_buffers', which applies to both the request line and any header line:
https://github.com/nginx/nginx/blob/master/src/http/ngx_http_core_module.c#L3544
-Dimitry
Date: Mon, 15 Dec 2025 01:46:24 +0100
On 15 Dec 2025, at 00:33, Daniel Stenberg <daniel_at_haxx.se> wrote:
>
> On Sun, 14 Dec 2025, Dimitry Andric via curl-library wrote:
>
>> Obviously, there is a limit to how large an MP4 you can send with it, and for anything larger you must use POST or PUT, but there is still something to be said for being able to choose a limit (preferably at run time) that makes sense for your particular use case.
>
> It seems rather ineffective to base64 it just to be able to put it in the URL!
>
> I really want us to avoid adding an option for this. We already have too many options. We need docs, tests and more to maintain every option and every option adds to the haystack in which users needs to find their needles when they look for specific options.
Yeah, that is perfectly understandable. The default now is probably a bit high, it makes sense to lower it.
>> E.g., we usually also configured Apache with "LimitRequestLine 100000000",
>
> Wow.
I looked it up, the actual default is 8190 (probably to account for the \r\n):
https://github.com/apache/httpd/blob/trunk/include/httpd.h#L195
Nginx also uses 8k, the directive there is 'large_client_header_buffers', which applies to both the request line and any header line:
https://github.com/nginx/nginx/blob/master/src/http/ngx_http_core_module.c#L3544
-Dimitry
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2025-12-15