💾 Archived View for gemi.dev › gemini-mailing-list › 000214.gmi captured on 2024-08-31 at 16:13:40. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Hi all! After eight hours of struggle yesterday, I finally made an MVP for Git.gmi, a CGI script that serves as a git frontend like cgit and git.sr.ht. It currently supports viewing repo index, summary, tree, textual blob, and commit log. Unlike gemgit it is not a static site generator, but a real, dynamic application. Here is a demo page: => gemini://fkfd.me/git/cgi/ It *may* work (or it may not); if you encounter status code 42, this could be the server or browser messing up relative links. Try fiddling with the URL in the address bar, like checking for missing/extra slashes. Repo (which you can also view on the demo above, of course): => https://git.sr.ht/~fkfd/git.gmi ~fkfd
It looks like the page at gemini://fkfd.me/git/cgi sends a bad header line. The server responds with a header of `20 SUCCESS text/gemini`, which means a status code of 20 (which means success), and a mime type of "SUCCESS text/gemini", which isn't a valid mime type, and isn't recognized as one by any client I know of. Looking in gemini://fkfd.me/git/const.py, it seems you define all of your status codes this way. Just replying with `20' is the behavior required for a client to know what to do with your response. Having changed that, I haven't been able to get anything other than 42 statuses on your demo or a server of my own, but I'm sure there's some way to fix it, like you mention in your announcement. This could still be beyond way cool tho, given that gemini requires the web to proliferate itself rn, outside of just hosting tarballs or whatever. Best, ~lel
On 6/14/20 2:11 PM, lel wrote: > It looks like the page at gemini://fkfd.me/git/cgi sends a bad header line. Just FYI, jetforce doesn't inform git.gmi of the existence of a slash at the end of a CGI PATH_INFO, so `/git/cgi` and `/git/cgi/` are requests for the same page; but the relative links differ in behavior: `=> tree/` links to `/git/tree/` and `/git/cgi/tree/`, respectively. > The server responds with a header of `20 SUCCESS text/gemini`, which means a status code of 20 (which means success), and a mime type of "SUCCESS text/gemini", which isn't a valid mime type, and isn't recognized as one by any client I know of. Looking in gemini://fkfd.me/git/const.py, it seems you define all of your status codes this way. Just replying with `20' is the behavior required for a client to know what to do with your response. Oh! I totally let slip of that. My testing client doesn't care about mimetypes; it just renders in text/gemini whatsoever. It should be correct in the next commit. > Having changed that, I haven't been able to get anything other than 42 statuses on your demo or a server of my own, but I'm sure there's some way to fix it, like you mention in your announcement. This could still be beyond way cool tho, given that gemini requires the web to proliferate itself rn, outside of just hosting tarballs or whatever. I haven't written up the Usage part yet in the documentation. You need to change a few hardwired lines like the shebang in the CGI entry executable, `cgi`, as well as other configs in `const.py`. I'll get around to it. ~fkfd
Most things should be fixed now. Things won't break as long as one clicks the "canonical" links as provided by the server, and does not tamper with the trailing slash. => gemini://fkfd.me/git/cgi/ Take a look? I'm, shamelessly, also self-advertising and asking for someone to list git.gmi in gemini.circumlunar.space/software/ . ~fkfd
On Sun, Jun 14, 2020 at 10:37:41PM +0800, Frederick Yin wrote: > I'm, shamelessly, also self-advertising and asking for someone to list > git.gmi in gemini.circumlunar.space/software/ . Done! Cheers, Solderpunk
---