Hi Rivo, So, if I understand this correctly, you need Django to figure out, whether you need to serve the static HTML page or not.
In this case, you could use http://wiki.nginx.org/X-accel; that is, return a HttpResponse with the X-Accel-Redirect header pointing to the static file. I suppose this is the most efficient way to serve static files only when certain conditions are met (e.g. you need a permission check first), without using Django to actually send the file. I hope this helps. Apostolis On Tue, Jan 14, 2014 at 11:52 PM, Rivo Laks <[email protected]> wrote: > Nono, I need Django for the API and backend logic :-) > > Let me illustrate my needs a bit better: > - I have Django instance that serves API and a few related services and > handles backend logic. > - I also have nginx server in front of the Django instance, that also serves > static files (css/js, which are always under /assets/ url prefix). > - There are some url prefixes such as /api/* that have to be handled by the > Django app. > - All the other urls should be responded to with my static index.html file. > Almost like a 404 handler that responds with static file. > > I suppose I could add all the prefixes that should be handled by the Django > app into nginx config. Matching requests would then be forwarded to the > Django app and all others would be handled by nginx. > But I'd rather not do that, since then I'd have to also keep the nginx > config in sync when I add another prefix to be handled by Django. > The number of prefixes probably wouldn't hit double digits, so maybe it is > the way to go, but I'm still wondering if there's a good way to handle it > inside Django. > > Rivo > > teisipäev, 14. jaanuar 2014 23:02.43 UTC+2 kirjutas Aymeric Augustin: >> >> You don’t need an application server running Django to serve a file. A >> plain and simple web server such as Apache or nginx will do. >> >> It’s a good practice to put application servers behind a web server acting >> as a reverse proxy (and possibly load balancer), so you probably have one >> already. >> >> It’s possible to serve the same page on any URL, it’s just a matter of >> writing the appropriate configuration for the server you’re using. >> >> I hope this helps! >> >> -- >> Aymeric. >> >> >> >> On 14 janv. 2014, at 21:18, Rivo Laks <[email protected]> wrote: >> >> Hm, indeed. >> >> Is there any better alternative or best practice for my usecase though? >> Basically I want a view that responds with contents of a static file and >> django.views.static.serve() does pretty much exactly that. Or is my usecase >> just too fringe to be handled by Django core? >> >> Rivo >> >> esmaspäev, 13. jaanuar 2014 22:49.33 UTC+2 kirjutas Marc Tamlyn: >>> >>> `django.views.static.serve` is, in the words of the documentation, >>> grossly inefficient and probably insecure, so it is unsuitable for >>> production. Any attempt to make it more useful than its current use case >>> (serving staticfiles in development) is unlikely to happen. >>> >>> Marc >>> >>> >>> On 13 January 2014 20:39, Rivo Laks <[email protected]> wrote: >>>> >>>> Hi everyone, >>>> >>>> I'm proposing to split out from the django.views.static.serve() view the >>>> functionality to serve a single static file. >>>> The new view could be named serve_file(), would take request and >>>> fullpath as parameters and would serve the given file. The code would >>>> essentially be the second half of the current serve() view. >>>> The serve() view could then be modified to use serve_file(), once the >>>> fullpath has been found and isdir() check is done. >>>> >>>> My usecase: >>>> I'm writing a single-page javascript app, using Django for backend logic >>>> and API. The client side consists of js/css assets and a single html file. >>>> I >>>> want that html file to be served by the Django app whenever a user makes a >>>> request to a url that doesn't match anything else (e.g. api urls). The >>>> javascript app does its own url routing, so if the user comes to /foo/bar >>>> , the same html file is served and the javascript shows the right page to >>>> the user. >>>> ATM I've created a fallback view that contains copy-paste code from >>>> serve() and has the fullpath variable hardcoded. The reason I like serve() >>>> is that it contains some useful logic, such as being able to respond with >>>> 304 (Not Modified) and setting some useful http headers. >>>> >>>> I can take care of creating a patch if the idea sounds good. >>>> >>>> Rivo >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Django developers" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> Visit this group at http://groups.google.com/group/django-developers. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/django-developers/5d9f0449-2b46-4c50-81f5-3b2e43e16512%40googlegroups.com. >>>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/django-developers. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/9db7ff84-8d44-4a03-b426-0af9e043d150%40googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/c15fefc6-a46b-493b-8f3a-f92b16ffdfcf%40googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAEa3b%2BpjYf-crHMSY_xkerEkoxEb4jH5_NogevS-63c%2BXZnnuA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
