HSTS: cap the list at 1,000 entries

Avoid never-ending growth.

When adding more entries, it now deletes the first entry in the list,
which is the oldest added entry still held in memory. I decided to avoid
a Least Recently Used concept as I suspect with a list with this many
entries most entries have not been used, and we don't save the timestamp
of recent use anyway.

The net effect might (no matter what) be that the removed entry might
feel a bit "random" in the eyes of the user.

Verify with test 1674

Ref #21183
Closes #21190
This commit is contained in:
Daniel Stenberg 2026-04-01 10:24:06 +02:00
parent 4f3a0ef90d
commit 03a792b186
No known key found for this signature in database
GPG key ID: 5CC908FDB71E12C2
6 changed files with 139 additions and 2 deletions

View file

@ -223,7 +223,7 @@ test1650 test1651 test1652 test1653 test1654 test1655 test1656 test1657 \
test1658 test1659 test1660 test1661 test1662 test1663 test1664 test1665 \
test1666 test1667 test1668 test1669 \
\
test1670 test1671 test1672 test1673 \
test1670 test1671 test1672 test1673 test1674 \
\
test1680 test1681 test1682 test1683 test1684 test1685 \
\

38
tests/data/test1674 Normal file
View file

@ -0,0 +1,38 @@
<?xml version="1.0" encoding="US-ASCII"?>
<testcase>
<info>
<keywords>
unittest
HSTS
</keywords>
</info>
<client>
<features>
unittest
HSTS
</features>
# This date is exactly "20190124 22:34:21" UTC
<setenv>
CURL_TIME=1548369261
</setenv>
<name>
HSTS load more than 1,000 entries from file
</name>
# test 1674 renders the input file itself, then reads it
<command>
%LOGDIR/hsts%TESTNUMBER
</command>
</client>
<verify>
<stdout>
Number of entries: 1000
</stdout>
<limits>
Allocations: 1100
</limits>
</verify>
</testcase>