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/
>
> 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 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
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 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,
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,
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
