On 11/5/05, Luke Plant <[EMAIL PROTECTED]> wrote:
> 3) implement the stack of middleware as you described it, which would
> solve this problem, but I don't know if it might introduce some others.
4) Change middleware to work like WSGI middleware-applications. A
middleware would be initialized wit
On 11/5/05, Luke Plant <[EMAIL PROTECTED]> wrote:
> I agree that functionality shouldn't be added until we have a use case,
> and the concept of walking up and down the stack helps. It's not quite
> that simple though -
Hmm... I thought the handlers did the right thing, damn :-(
> Solutions:
>
On Sat, 5 Nov 2005 14:31:30 +0100 Sune Kirkeby wrote:
> On 11/5/05, hugo <[EMAIL PROTECTED]> wrote:
> > I think the reversed order is just counter-intuitive - you just
> > don't think about it when adding middleware and talking about
> > middleware.
>
> It's perfecetly obvious to me. I think of
On 11/5/05, hugo <[EMAIL PROTECTED]> wrote:
> I think the reversed order is just counter-intuitive - you just don't
> think about it when adding middleware and talking about middleware.
It's perfecetly obvious to me. I think of it like a normal call-stack;
the request walks down the middleware-st
>Also, can you come up with an actual middleware, which needs
>to run in different places in the req. and resp. chains? Otherwise
>this whole discussion is a bit academic, and the code to handle
>it in django would be cruft.
As I wrote in the ticket #730: the LocaleMiddleware needs to come in
pro
On 11/4/05, Luke Plant <[EMAIL PROTECTED]> wrote:
> Yes, I like this idea. As I was working with this I found myself think
> a number of times that with a couple more middleware's thrown into the
> mix and you could easily have an impossible set of constraints to
> satisfy.
Actually, if you have
> This should definitely be clarified in the documentation. Actually I
> think it might even make sense to have an additional setting where you
> give an explicit order of middleware to use in the response phase -
> that way you could even have different order in request and response
> phase. Wou
>Am I missing something? This makes quite a big difference, since you
>could end up serving private data to the wrong person if you get it
>wrong.
No, I think you got it right. The reverse order of middleware in the
response phase does make sense, but it is a bit counter-intuitive at
some times
Hi Hugo, everyone,
Sorry for the reply to such an old e-mail - I dug it out after coming
across problems while developing my own middleware.
> They can have allmost any order you like, but you have to make sure
> that the cache middleware is after all middlwares that might change
> content depen
Georg,
Thank you for comprehensive answers. I think the part about interaction
between different types of middleware should go directly to Django's
documentation.
Thanks,
Eugene
"hugo" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
>
> Hi,
>
>>1) If I want to use all 3 cache mi
Hi,
>1) If I want to use all 3 cache middlewares + session middleware, what is
>the correct order now? Is this stack correct:
They can have allmost any order you like, but you have to make sure
that the cache middleware is after all middlwares that might change
content depending on headers - for
It's very good that Sune's and George's additions finally made their way
into Django. They brought more structure to http handling.
Now it is high time to start Q&A session. Qs:
1) If I want to use all 3 cache middlewares + session middleware, what is
the correct order now? Is this stack corre
On 10/8/05, hugo <[EMAIL PROTECTED]> wrote:
> No, but it will give correct Vary header and set some Cache-control
> headers. Usually frameworks just ignore this stuff and send out stuff
> like Cache-control: private or even Pragma: no-cache - in fact
> disabling caching completely. Django will sen
Hi,
> Do you mean that django will be ICP protocol compatible ??
No, but it will give correct Vary header and set some Cache-control
headers. Usually frameworks just ignore this stuff and send out stuff
like Cache-control: private or even Pragma: no-cache - in fact
disabling caching completely.
Le Samedi 8 Octobre 2005 22:35, hugo a écrit :
> A nice side-effect of the patch: django will be one of the first python
> web frameworks that fully interoperates with accellerator proxies like
> squid without degrading them to simple forwarders (like Pragma:
> no-cache or Cache-Control: none woul
On 10/8/05, hugo <[EMAIL PROTECTED]> wrote:
> I today worked on ticket #580 to make the caching work better with
> dependencies on headers. The problem: the current caching won't take
> into account many HTTP headers and won't be easily configureable for
> new headers. So for example if your page
Hi,
I today worked on ticket #580 to make the caching work better with
dependencies on headers. The problem: the current caching won't take
into account many HTTP headers and won't be easily configureable for
new headers. So for example if your page content is based on cookies,
the cache middlewa
17 matches
Mail list logo
