Use nginx? http://nginx.org/en/
Cheers, AT On Tue, Jan 14, 2014 at 6:18 PM, Rivo Laks <rivol...@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-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/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/CAKBiv3z5US9prD81MS6z6Pb9tUKZDF--_VKaAF6djb%2BFCe5_5g%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
