Re: [PATCH] http-backend: give a hint that web browser access is not supported

On Sunday 2021-12-05 02:17, Junio C Hamano wrote:

quoted

quoted

What is in "pathinfo" parameter?

It is getenv("PATH_INFO").

That part I know.  The question was what would a typical value of
that parameter look like in the context of somebody mistakenly
visiting Git smart HTTP endpoint via their browser.

As far as I can tell, it contains the request URI plus index.html resolution;
https://git.inai.de/ reports /index.html while
https://git.inai.de/foo reports /foo (since foo does not exist in the fs).

I am basically wondering if it is helping the user enough, or if it
is sufficient to give just the "err" and "hint", and nothing else.

I felt that, because ls(1) reports the filename again, e.g.

$ ls x
ls: cannot access 'x': No such file or directory

that git-http-backend could do the same, especially since
pathinfo isn't just $ENV{REQUEST_URI} again at all times.

quoted

Yes, that seems more like it. I was not aware of send_strbuf.

Heh, I wasn't either.  The review of this topic was the first time I
seriously read any part of that file, and I think I still only read
just about 20% of it ;-)

Also, will the real Git clients, which are the primary intended
audiences this program is trying to talk to, be OK if we suddenly
start giving a non-empty 404 page?

I am confident enough to say yes. It's not like git-http-backend
returned anything previously in the 404 case (like JSON or so),
therefore clients could not possibly depend on content.

If any implementations of Git HTTP client this program is serving
(1) uses a 404 response as a cue to decide its next request
(e.g. there may be some "try this URL and if it fails, do another
one" fallback logic)

Not sure if they heed Location: headers, but I am not changing
that :-)