Re: Supporting git access via smart HTTPS protocol for musl-libc

[Drew DeVault <sir@cmpwn.com>]

On 2019-03-26 11:47 AM, Rich Felker wrote:
> I don't see why thttpd is making it difficult. It makes routing with
> haproxy difficult only because haproxy is more pedantic than any web
> browser is about headers, but I don't want to use haproxy routing
> anyway.

Does thttpd even have routing at all? As far as I can tell it is not
capable of sourcing routes from anywhere other than the filesystem. This
makes conditionally dispatching requests to git difficult. Perhaps I
misunderstand how this kind of thing could be configured with thttpd?

> I'd love to have a modern one with the same type of design.
> Unfortunately all the modern ones are hideous.

The design is what's antiquted.

> > I'd vote in favor of switching to nginx, in the
> 
> nginx doesn't even support cgi. It just forwards to another server for
> cgi. It's also horribly bloated and enterprise-ey. In 5-10 years it
> will go exactly the same way Apache did. Watch for them to have their
> own Tomcat but for whatever language displaces Java...

I agree on all of these points, but I'd like to draw attention to the
fact that 5-10 years from now is 5-10 years from now. That's plenty of
time to come up with a better httpd, and in the meanwhile nginx has yet
to go the Apache way.

> > However, the other suggestion of busybox httpd + git-http-backend seems
> > reasonable to me. It sounds like you were hoping to keep thttpd in play,
> > though, which seems folly to me.
> 
> If it works with busybox httpd it should work with thttpd.

I admit that I know little about busybox httpd, but assumed that the
opinion expressed earlier in the thread about its viability was an
informed one. However, upon studying thttpd's documentation, I concluded
that it was not up to this task without egregious hacks.

A similar survey of busybox httpd agrees that serving git should be
possible, though somewhat convoluted - less so than thttpd would be.