Stefan Sperling <stsp@stsp.name> wrote:
> On Mon, Dec 01, 2025 at 11:17:39PM +0100, Omar Polo wrote:
> > [...]
> > I think we should 'fix' this and at least enable auth for the website.
> > I think it doesn't make much sense to protect the history but not the
> > resulting tree at the tip :p
> 
> I am not sure what value authentication would add to this feature.
> 
> The reason we need authentication is either to protect a private repository
> or to block web crawlers from hitting expensive pages like diff and blame
> over and over, wasting resources.

I got the idea for the use-case by reading your EXAMPLES section.  if we
have, say, the doc exposed as /doc/api/1.x/ and the repo itself is
private (not talking about crawler protection) then why not having the
doc private as well?  I'm seeing this mostly as an utility service,
where you can also browse some doc privately.

but this can be mostly noise at this point, I don't have a real use-case
for it and if you don't think it's useful, let's wait for feature
requests :)

> Regarding private repositories:
> 
> The website feature is intended to be used for non-interactive web sites,
> such as software project landing pages which introduce a project and link
> to other resource related to it. Such pages are usually public and do not
> process input beyond parsing GET requests. Putting authentication in front
> of them reduces discoverability to a point where it does not really make
> much sense to have a landing page in the first place.
> 
> The website files might even be stored in a private repo. If so, the admin is
> making a concious decision to expose part of that private repo as a web site.
> I don't see a problem with that. The exposure is limited to a specific branch
> and/or subdirectory, and must be explicitly enabled via 'website' statements
> in the config file.
> 
> 
> Regarding crawlers:
> 
> Serving trees/blobs without further processing is not very expensive overall.
> The most expensive part of this is decompression, both in terms of zlib and
> deltas. This will usually be fast enough that we won't need to worry about
> crawlers. Should this become a problem we can add a persistent in-memory
> cache for website content to gotwebd and just copy any relatively small files
> out directly from RAM, reducing overhead to the minimum possible with FastCGI.