If you're on nginx, There are also some cases where you may find X-ACCEL-REDIRECT useful, which allows you to return a blank HTTPResponse from Django and tell nginx to serve a file.
Nginx Docs: http://wiki.nginx.org/X-accel Blog post: http://www.wellfireinteractive.com/blog/nginx-django-x-accel-redirects/ In any case, this is now more suited to a Django-users discussion. If you ask there, I'm sure there may be other possible solutions people know of. Thanks, Marc On 14 January 2014 21:52, 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/CAMwjO1HNCLeYP0em4Z0WGNvBqfUVxLMd%3DGH7X9CJT0DW%3DaY-5g%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
