Upstream has switched to cpp-httplib after the latest release, which I have packaged. Unfortunately that does not offer any decent parsing of URL, which would separate URL text into separate components.
Yes, if http-parser is going to be removed, we may return to bundled url_parser. Or we could use libcurl-url(3) for parsing URL. I would have expected that would be implemented in every HTTP library, but it does not seem so.
Flamethrower uses this only to split URL string into separate components. Curl offers that for sure. It is unnecessary big dependency, but probably installed even in minimal installation already. libcurl-minimal has size under 1MB, which is good enough.
I have pushed change back to bundled url-parser as a first fix. We may want to use something small enough. Candidates are:
- uriparser
- ada-url
Some of these might be proposed to upstream, ideally in for of PR.
On Tue, Dec 10, 2024 at 9:26 AM Petr Špaček <pspacek@xxxxxxx> wrote:On 09. 12. 24 15:32, Stephen Gallagher wrote:On Mon, Dec 9, 2024 at 9:30 AM Stephen Gallagher<sgallagh@xxxxxxxxxx> wrote:On Sat, Dec 7, 2024 at 12:21 PM Carlos Rodriguez-Fernandez <carlosrodrifernandez@xxxxxxxxx> wrote:I took sparse, and http-parser. http-parser in particular is a dead project upstream. However, there is a good set of packages depending on it. There are also past contributors. If any of the past contributors want to take it please let me know, I'll be happy to hand it over: dck, mrunge, orphan, patches, sgallagh, vascom.I actually thought I'd removed myself from that package; I've migrated all of the packages I used to maintain with http-parser over to the (supported) llhttp package. The upstream is very dead and it's been strongly implied to me that there are very likely to be security issues with it. I'd argue that we need to remove it from the distribution entirely and either fix or retire the remaining packages depending on it: * AusweisApp2-0:2.2.1-1.fc41.x86_64 * AusweisApp2-0:2.2.2-2.fc41.x86_64 - Upstream still relies on http-parser and needs to be contacted to migrate to a maintained parser. * flamethrower-0:0.11.0-28.fc41.x86_64 - This is actually carrying a Fedora-specific patch to use http-parser instead of upstream's private fork (called url_parser). Given that both of them are effectively unmaintained, I think we want to drop our patch and follow upstream (and contact them about switching to a maintained parser)FTR Flamethrower upstream is inactive. Last time I spoke to people who are in charge of the upstream repo they had no time to maintain it. If we have a working patch which just needs to be folded upstream that can be done, I guess, but I would not bet on a proper release with tarball and all that.We have a working patch, but it's to let Flamethrower use http-parser, which is now ALSO unmaintained. So my proposal was that we should just DROP our patch. If flamethrower is unmaintained anyway, there's no good reason for us to be carrying an alternate, but also-unmaintained dep. Now, if someone wants to do the work to switch it over to llhttp, that's worth considering. I can point at two cases where we migrated from http-parser to llhttp for inspiration: * libgit2: https://github.com/libgit2/libgit2/pull/6713 * tang: https://github.com/latchset/tang/pull/136 and https://github.com/latchset/tang/pull/140
I am not sure we want to migrate to llhttp. It contains no documentation in current package. CURL has excellent documentation.
The main problem is flamethrower's upstream tries to bundle everything needed into the repo. I doubt we want that done with curl too. But if we should replace bundled url_parser, I would vote for libcurl. Even though it would duplicate already present cpp-httplib parser.
OTOH the tool is useful and the DNS community is using it because it 'mostly works'. Not sure if we want to keep it in Fedora? Opinions?If we want to keep it in Fedora, we probably need to do the work to migrate it to a maintained parser.
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
