💾 Archived View for gemi.dev › gemini-mailing-list › 000151.gmi captured on 2024-05-26 at 15:23:04. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Hi all, I noticed an interesting error in my server log: status=51 request=gemini://gem.1.21jiggawatts.net/posts/favicon.ico I guess somebody is experimenting with this in a client - it looks like it was an automated request following a .gmi file. What's odd is that it's looking in exactly the same directory as the page that was requested, rather than the domain root. It strikes me as a bug but I thought I'd bring it up to see if anyone thinks otherwise! Cheers, Tom
It was thus said that the Great Thomas Karpiniec once stated: > Hi all, > > I noticed an interesting error in my server log: > > status=51 request=gemini://gem.1.21jiggawatts.net/posts/favicon.ico > > I guess somebody is experimenting with this in a client - it looks > like it was an automated request following a .gmi file. What's odd is > that it's looking in exactly the same directory as the page that was > requested, rather than the domain root. > > It strikes me as a bug but I thought I'd bring it up to see if anyone > thinks otherwise! I found requests for favicon.ico from last week. Perhaps it's a web proxy? Anyway, I set up my server to serve up a favicon.ico no matter where it's requested (oh yeah, new feature to GLV-1.12556). -spc (That shouldn't be a problem, right?)
> I found requests for favicon.ico from last week. Perhaps it's a web > proxy? I would guess it's a Gemini client experimenting with the idea of favicons in Gemini, which have certainly been proposed. See, e.g.: gemini://mozz.us/journal/2020-04-17.gmi plus discussion elsewhere on this list (where somebody proposed using a single UTF-8 encoded emoji as an ultralight favicon, which is a cute idea). > Anyway, I set up my server to serve up a favicon.ico no matter where it's > requested (oh yeah, new feature to GLV-1.12556). > > -spc (That shouldn't be a problem, right?) Well, it's not really within the scope of the Gemini spec to explicitly forbid things like this. If people want to write clients which do it, nobody can stop them. If people want to do it, I strongly encourage them to make it an option the user can easily disabled. Some people, myself included, hold the "one request per page" principle in very high regard, so I probably wouldn't add this to a client of mine, even if I had a graphical one where it made sense. I do grant that, as far as "secondary requests" not under direct control of the user go, this is probably the least harmful kind possible, where the path is fixed and it goes to a server that the user has already agreed to visit. Cheers, Solderpunk
On Tuesday 26 May 2020 19:23, solderpunk <solderpunk at SDF.ORG> wrote: > Well, it's not really within the scope of the Gemini spec to explicitly > forbid things like this. If people want to write clients which do it, > nobody can stop them. If people want to do it, I strongly encourage > them to make it an option the user can easily disabled. Some people, > myself included, hold the "one request per page" principle in very high > regard, so I probably wouldn't add this to a client of mine, even if I > had a graphical one where it made sense. Useless network usage... "One request to rule them all" :-)
On Tue, May 26, 2020 at 05:23:29PM +0000, solderpunk wrote: > Well, it's not really within the scope of the Gemini spec to explicitly > forbid things like this. If people want to write clients which do it, > nobody can stop them. If people want to do it, I strongly encourage > them to make it an option the user can easily disabled. Some people, > myself included, hold the "one request per page" principle in very high > regard, so I probably wouldn't add this to a client of mine, even if I > had a graphical one where it made sense. That's my attitude also. If someone wants to expend a TLS session for a tiny picture then that's their business. :) Thanks for the comments all. Clearly there is no consensus whatsoever on how favicons work so there is no right or wrong. It's interesting to hear about the special casing in GLV-1.12556. Cheers, Tom
It was thus said that the Great Thomas Karpiniec once stated:
> Thanks for the comments all. Clearly there is no consensus whatsoever
> on how favicons work so there is no right or wrong. It's interesting
> to hear about the special casing in GLV-1.12556.
It's not that special of a special case. I just added the feature to
serve up a single page:
handlers =
{
{
path = "^/motd$",
module = "GLV-1.handlers.file",
file = "/etc/motd"
},
...
}
In the above example, it's for serving up a page that might not live in
a directory with the rest of the content. The "path" defines the path
portion of the URL to be matched, so for the favicon.ico, all I had to do
was:
handlers =
{
{
path = "^/.*favicon.ico$",
module = "GLV-1.handlers.file",
file = "/path/to/favicon.ico"
},
...
}
and made sure this was the first path checked.
-spc
---