How to handle files like robots.txt and favicon.ico under nginx?

vsajip

johns Ah, I know you can do that, thanks. I meant if there was some other way to use nginx to serve these, as these are static files expected to be found at the site root.

sean

vsajip At this time you'll need to do it in your Django setup as John suggested. The reason is that since you're serving your Django app from the root of the site, we can't tell the front-end to serve static stuff from that same URI.

Not saying its impossible, we're just not set up to do it that way yet. I'll open an internal ticket to see if we can implement in the future.

webtweakers

Out of curiosity, is there a better way to serve /favicon.ico by now?

Some browsers are ignoring the set of html tags, like:
<link rel="shortcut icon" href="/static/favicon.ico">

nick

webtweakers

It's been a while for me but I think it needs to be 'rel=icon' (EDIT: looks like both work). And I suppose 'type' and 'sizes' are now used for specificity/compatibility. The wikipedia article on the topic is also quite interesting, has a lot to say.

Ref: https://en.wikipedia.org/wiki/Favicon
Ref: https://www.w3schools.com/tags/att_link_sizes.asp

webtweakers

nick
I know, I have a set of those icon tags, for specific devices, etc.

Problem is that some browsers still request /favicon.ico, from the root of the domain. As @sean said, Django is being served from the root, so can't have both. The only option seems to be @nathan's suggestion.

I was just wondering if, by now, there is a better solution.

sean

webtweakers you can uwsgi's static routing capabilities, eg you could add this to your uwsgi.ini:

route = /favicon.ico static:/home/shelluser/apps/appname/favicon.ico

In that setup the file will be served directly by your uwsgi instance but without going through Django's template machinery.

webtweakers

That's exactly the kind of thing I was looking for. Except, I'm using Gunicorn, where this route-functionality does not exist, I think. I suppose this would be one good reason to switch to using uwsgi.

sean

webtweakers another approach would be to run your own Nginx server on the back end, using a port assigned via a proxy port app and configured to serve whatever static assets you need and to proxy everything else to gunicorn.

Probably too much work for a favicon in my opinion 🙂

webtweakers

So, while playing with the installation of my Django/Python projects on the new AlmaLinux 9 server, I was considering to replace gunicorn with uwsgi... only to find that the uwsgi project is now in maintenance mode.

So now I am considering Granian.

Does anyone have experience with this? Any positives or negatives? Is there an obvious reason I should NOT use this?

sean

webtweakers This article has a decent breakdown of pros and cons for various Python app servers, including Granian.

Having no experience with Granian, I'm inclined to agree with the article that its biggest downside would be that it is very new compared to the other options and so it may be harder to find a solution if you run into a problem with it.

That said, I know you run a busy site and if the performance is that much better under Granian then it's worth a try.

webtweakers

Thanks, Sean, that was helpful. As that comparison article points out: Gunicorn sits at one side of the spectrum and Granian sits at the other side being less memory intensive and much faster at the same time. With these things in mind it seems worth trying out. And taking into account what you mentioned, I suppose it's wise to have a fallback (good old Gunicorn) prepared in case it's required.

On a side-note: I haven't been bothering with async programming, since I know Gunicorn doesn't support it. By replacing it with a compatible app server, I could start using more modern techniques as well. Django's compatibility has improved greatly recently, as well.

Oh, and additionally, the thing that started this topic: Granian supports static files, whereas Gunicorn does not! 🙂