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] <javascript:>>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] <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/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.
