Malcolm Tredinnick wrote:
> So, as an addition to the current behaviour, I'm probably +1 on
> including this. There's a bit of common stuff we can factor out from
> that code to avoid duplication with the middleware and other ETag
> handling code people might want to write, but that's minor stuff.
Jeremy Dunck wrote:
> Neat-o. License? If it's OK, I'll use it whether it goes into django
> trunk or not. :)
Let's say it's BSD. This is a part of the tutorial on writing forum in
Django and I didn't think about wrapping it as a product. But if I did
it would be BSD usually :-)
--~--~-
On Sat, 2007-10-20 at 01:20 +0400, Ivan Sagalaev wrote:
> Hello!
>
> A similar issue was raised on this list some time ago but as far as I
> remember there wasn't any proposed solution. I think I have a good one.
>
> I'm trying to solve a problem with the current implementation of
> conditiona
On 10/19/07, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> I didn't file a ticket for this yest because I vaguely remember some
> opposition to the whole idea of trying to optimize current conditional
> get behavior. I'd like to raise this issue again and if it turns out
> that people like the idea I
On 10/19/07, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> As a solution I propose a view decorator taking as a parameter a
> function calculating Last-Modified and/or ETag that takes care of all
> the mechanic of checking request headers, returning 304 Not Modified
> and setting response headers. It
Hello!
A similar issue was raised on this list some time ago but as far as I
remember there wasn't any proposed solution. I think I have a good one.
I'm trying to solve a problem with the current implementation of
conditional get where ETag and Last-Modified are taken into account only
after
