Re: Feature request: serve_file() view in static app
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 >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 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 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
Re: Feature request: serve_file() view in static app
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 > > 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 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.
Re: Feature request: serve_file() view in static app
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 >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.
Feature request: serve_file() view in static app
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-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/5d9f0449-2b46-4c50-81f5-3b2e43e16512%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
