X-accel looks promising, I'll see if it can solve my problem. Thanks! Rivo
teisipäev, 14. jaanuar 2014 23:58.13 UTC+2 kirjutas Marc Tamlyn: > > 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] <javascript:>>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] <javascript:>. >> To post to this group, send email to >> [email protected]<javascript:> >> . >> 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/3d155a69-4e73-44ea-a986-aa43f0397270%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
