Open
Labels
bugConfirmed bugs or reports that are very likely to be bugs.Confirmed bugs or reports that are very likely to be bugs.
Description
Prerequisites
- Put an X between the brackets on this line if you have checked that your issue isn't already filed: https://github.com/search?l=&q=repo%3Aetr%2Flibhttpserver&type=Issues
Description
Some digging around for other reason shows that http_endpoint::operator< is unconditionally case-insensitive. This strongly implies that there are gaps in the test suite relating to builds with -DCASE_INSENSITIVE.
Steps to Reproduce
Play around with this: 518a966
Expected behavior: Test coverage both with and withou -DCASE_INSENSITIVE and the cases where they differ.
Actual behavior: A test I added for one case surfaced a bug.
Versions
Current master.
Metadata
Metadata
Assignees
Labels
bugConfirmed bugs or reports that are very likely to be bugs.Confirmed bugs or reports that are very likely to be bugs.
Activity
Fix issue etr#310, but may break existing users.
etr commentedon Jul 23, 2026
Update for libhttpserver 2.0 — partially addressed, but leaving this open.
The dispatch-time impact is gone: v2's 3-tier route table is now the sole routing oracle and is consistently case-sensitive by default. It replaces the v1
registered_resourcesordered map whose key comparator (http_endpoint::operator<) was the unconditionally case-insensitive one you flagged.test/integ/basic.cppalso gained#ifdef CASE_INSENSITIVErouting probes.However, the underlying gap this issue is about remains:
--enable-case-insensitiveconfigure option and no CI lane that builds with-DCASE_INSENSITIVE, so those probes are never compiled or exercised.http_endpoint::operator<is still unconditionally case-insensitive viastd::toupper(now vestigial, but unchanged).Leaving this open to track adding a real
-DCASE_INSENSITIVEbuild + test lane.