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 <rivol...@gmail.com> 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 <rivo...@gmail.com> 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 <rivo...@gmail.com> 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 django-develop...@googlegroups.com. >>>> To post to this group, send email to django-d...@googlegroups.com. >>>> 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 django-develop...@googlegroups.com. >> To post to this group, send email to django-d...@googlegroups.com. >> 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 django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. 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.
