From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Jeff King <peff@peff.net>
Cc: Milan Hauth <milahu@gmail.com>, git@vger.kernel.org
Subject: Re: Git dumb HTTP protocol should work without update-server-info
Date: Mon, 8 Sep 2025 21:27:23 +0000 [thread overview]
Message-ID: <aL9KOyR0eb7zAg2R@fruit.crustytoothpaste.net> (raw)
In-Reply-To: <20250908000543.GB1281511@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 2004 bytes --]
On 2025-09-08 at 00:05:43, Jeff King wrote:
> Possibly dumb-http could learn to do the same scraping that httpdirfs
> does to get the refs and pack listings (though this might be quite slow
> for unpacked refs, if the ref tree is deep). But I doubt you will find
> anybody that enthused about working on or reviewing dumb-http patches
> these days. The code is not very well maintained, IMO.
That kind of scraping is really not a good idea.
It's the equivalent of trying to parse the FTP LIST output, which is
customarily the equivalent of `ls -l`, but doesn't have to be, and often
isn't on Windows. I can tell you from experience how painful doing that
is and how many bug reports come in when you try to use that (because
the FTP server also doesn't support either variant of the
machine-readable format that solves this problem).
It's also prone to breaking things because some HTTP servers have weird
redirect loops due to sorting entries in the index pages that you have
to be careful not to trigger. And, of course, that depends on the
server having index pages turned on, which many do not.
And then you have to do all of this in C with pointer arithmetic, with
all of the terrifying security properties that has, especially because
you can't actually use an XML parser to do it (unlike in DAV) since many
servers have index pages that are (possibly invalid) autogenerated HTML
3.2 or something.
I've seen exactly one piece of software (lftp) that hasn't done a
terribly awful implementation of this and that happens to have worked
every time I've tried it (which is extremely infrequently, so I probably
just haven't found a server which breaks it yet). Every other piece of
software I've used that's done this kind of thing has just been broken
and I anticipate Git would be no different.
I do want to be very clear that this is a bad idea and I hope never to
see such patches come into Git.
--
brian m. carlson (they/them)
Toronto, Ontario, CA
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
next prev parent reply other threads:[~2025-09-08 21:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-07 11:24 Git dumb HTTP protocol should work without update-server-info Milan Hauth
2025-09-07 15:07 ` brian m. carlson
2025-09-07 17:23 ` Milan Hauth
2025-09-07 17:42 ` brian m. carlson
2025-09-08 9:40 ` Patrick Steinhardt
2025-09-08 14:43 ` Junio C Hamano
2025-09-09 5:26 ` Patrick Steinhardt
2025-09-08 0:05 ` Jeff King
2025-09-08 4:14 ` Junio C Hamano
2025-09-08 21:27 ` brian m. carlson [this message]
2025-09-09 1:35 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aL9KOyR0eb7zAg2R@fruit.crustytoothpaste.net \
--to=sandals@crustytoothpaste.net \
--cc=git@vger.kernel.org \
--cc=milahu@gmail.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).