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: Andreas Mohr via curl-library <curl-library_at_lists.haxx.se>
Date: Sun, 14 Dec 2025 13:54:30 +0100
Hi,
On Sun, Dec 14, 2025 at 12:09:08PM +0100, Daniel Stenberg via curl-library wrote:
> When a user sets a URL in libcurl it allows up to an 8 megabyte string. If
> that URL uses a maximum amount of "../" occurances, all those need to be
> "optimized away" in the dotdot normalization phase of the URL parsing.
>
> That makes 2,666,663 three-byte sequences to remove in the worst possible
> case.
...
> Thoughts?
Hopefully curl is not implementing various string activity areas as
*in-place* string data replace activity (CPU cache adventures), but rather as
properly distinct (in-out data handling properly fully separated) activity.
(can make a performance difference to the tune of
e.g. a factor of a whopping 1000something with
multi-MBs strings *), from
own experience).
*) due to permanent *in-place re-writing* of
multi-MBs of string data (e.g. by
iteratively removing few "victim" bytes each in the *middle* of
MB-sized data)
I've now had a short look at CURL sources, and
dedotdotify() does seem to
have some (limited?) semi-mixed handling
(does apply some string truncation etc. to
out-side allocation **)).
**) this would not be the case with
fully cleanly separated parser <-> generator (in / out) handling
(though such clean handling may easily be
overkill in any rather "simple" situations)
Greetings
Andreas Mohr
Date: Sun, 14 Dec 2025 13:54:30 +0100
Hi,
On Sun, Dec 14, 2025 at 12:09:08PM +0100, Daniel Stenberg via curl-library wrote:
> When a user sets a URL in libcurl it allows up to an 8 megabyte string. If
> that URL uses a maximum amount of "../" occurances, all those need to be
> "optimized away" in the dotdot normalization phase of the URL parsing.
>
> That makes 2,666,663 three-byte sequences to remove in the worst possible
> case.
...
> Thoughts?
Hopefully curl is not implementing various string activity areas as
*in-place* string data replace activity (CPU cache adventures), but rather as
properly distinct (in-out data handling properly fully separated) activity.
(can make a performance difference to the tune of
e.g. a factor of a whopping 1000something with
multi-MBs strings *), from
own experience).
*) due to permanent *in-place re-writing* of
multi-MBs of string data (e.g. by
iteratively removing few "victim" bytes each in the *middle* of
MB-sized data)
I've now had a short look at CURL sources, and
dedotdotify() does seem to
have some (limited?) semi-mixed handling
(does apply some string truncation etc. to
out-side allocation **)).
**) this would not be the case with
fully cleanly separated parser <-> generator (in / out) handling
(though such clean handling may easily be
overkill in any rather "simple" situations)
Greetings
Andreas Mohr
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2025-12-14