Hi Tai,
On Tue, Sep 14, 2010 at 09:25:36PM -0700, Tai Lee wrote:
> I'm going to try and preempt a possible objection that has been raised
> in previous discussions on this subject.
>
> Won't this change require a lot of repetitive logic to be shifted into
> middleware functions? All middleware au
After re-reading the rest of those previous discussions, I see at
least one thing wrong with the "disabled_middleware" attribute
approach. 3rd party apps won't know which middleware is installed that
might break their responses, and end-users won't have a mechanism to
disable middleware for respons
I'm going to try and preempt a possible objection that has been raised
in previous discussions on this subject.
Won't this change require a lot of repetitive logic to be shifted into
middleware functions? All middleware authors will now need to inspect
the response and find out if they can make th
Hi,
On Tue, Sep 14, 2010 at 01:22:37AM +0100, Luke Plant wrote:
> It would be extremely useful to me if you could go through the use cases
> linked on the previous thread and see if your solution addressed them
> all.
Sorry, I'll have to get this out tomorrow. I ended up being a little short on
Hi,
I was re-reading this and wanted to clarify a few points.
On Mon, Sep 13, 2010 at 01:34:55PM -0400, Forest Bond wrote:
> Response Freezing
> =
>
> To address #1 and #2, I'd like to propose a response "freezing" API. The
> basic
> idea is that I can freeze a particular heade
Hi Luke,
On Tue, Sep 14, 2010 at 01:22:37AM +0100, Luke Plant wrote:
> you wrote:
> >
> > I'd like to return to the problem of middleware, view decorators, etc.
> > affecting
> > responses in negative ways.
>
> Thanks so much for all your hard work and persistence on this issue.
Thanks. Persi
Hi Forest,
you wrote:
>
> I'd like to return to the problem of middleware, view decorators, etc.
> affecting
> responses in negative ways.
Thanks so much for all your hard work and persistence on this issue.
Although I haven't gone through this in detail, I think this is arriving
at a good solu
Hi Santiago,
On Mon, Sep 13, 2010 at 03:58:12PM -0300, Santiago Perez wrote:
> The biggest problem with the approach I've proposed is that it is not
> sufficiently granular to handle the case where I don't want the response
> content
> modified (e.g. compressed) but I *do* want to
>
> The biggest problem with the approach I've proposed is that it is not
> sufficiently granular to handle the case where I don't want the response
> content
> modified (e.g. compressed) but I *do* want to return HTTP 304 Not Modified
> where
> appropriate. That's the only use case I can think of
Hi,
I'd like to return to the problem of middleware, view decorators, etc. affecting
responses in negative ways.
Background
==
Previous discussion on django-developers (this has come up more than once,
though, I think):
*
http://groups.google.com/group/django-developers/browse_thread/
10 matches
Mail list logo
