Re: Feature request: serve_file() view in static app

Hi Rivo, So, if I understand this correctly, you need Django to figure out, whether you need to serve the static HTML page or not. In this case, you could use http://wiki.nginx.org/X-accel; that is, return a HttpResponse with the X-Accel-Redirect header pointing to the static file. I suppose

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

Re: Testing parameters in database settings

On Tue, Jan 14, 2014 at 3:26 PM, Shai Berger wrote: > > The way testing currently works is by creating a throw-away database, > running > the tests on that, and throwing it away. This means, among other things, > that > you need settings for a database service and credentials

Re: Feature request: serve_file() view in static app

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:

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

Re: Feature request: serve_file() view in static app

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

Re: Testing parameters in database settings

Hi, On Tuesday 14 January 2014 21:35:04 Michael Manfre wrote: > Why are we not encouraging people to define different aliases for testing? > Many of those TEST_ settings could be given meaning to the database > configuration without being specific to running tests. Several of those > TEST_

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

Re: Testing parameters in database settings

I'm -0, on sweeping this explosion of settings (mostly for Oracle) under a "TEST" rug, instead of addressing the underlying problem. The entire TEST_* collection of settings is, in my opinion, a broken design that is used to shim a second "test" database configuration in a spot designed for a

Re: permit global change of BaseForm.label_suffix

On Saturday 11 January 2014 19:34:42 Tilman Koschnick wrote: > Hi, > > I'd like to bring up #18133 again, which has been closed as wontfix. > > I am looking for an easy and non-intrusive way to override the default > colon suffix on form field labels. The suggested methods of subclassing > the

Re: Testing parameters in database settings

+1, what Aymeric said. On 14 Jan 2014 17:50, "Aymeric Augustin" wrote: > This has bugged be for some time too. Fix it! > > Even if it's just for tests it would be nice to implement a simple > deprecation path. > > I'd simply call the new key TEST, but whoever

Re: Testing parameters in database settings

This has bugged be for some time too. Fix it! Even if it's just for tests it would be nice to implement a simple deprecation path. I'd simply call the new key TEST, but whoever writes the patch can choose the name :-) -- Aymeric. 2014/1/14 Shai Berger > Hi all, > >

Django Security & OWASP Project

Django Developers, Hello! Over at OWASP I've started a framework security project. Our goal is to capture the security posture, options and capabilities of different frameworks. Through this we can educate developers on how to enable security controls in the framework and also work with

Testing parameters in database settings

Hi all, Django's database settings currently support eleven separate parameters for testing, all named 'TEST_*', most of them more-or-less backend-specific (in fact, six -- already a majority -- are Oracle-specific). We have now discovered[1] that we need even more Oracle-test-specific

Re: Improving aggregate support (#14030)

I've also written a basic hack (there's no other word for it really) that should support the majority of custom aggregates out in the wild. The exact commit is here: https://github.com/jarshwah/django/commit/74c945db2e12444dd012cf89dbf65dddce84ba7b Basically, it checks to see if add_to_query