Re: [GMG-Devel] Question about Meddleware

[Nathan Yergler]

Comments inline below...

On Thu, Nov 29, 2012 at 1:20 AM, Sebastian Spaeth <address@hidden> wrote:
> Hi all,
>
> I am in the process of writing an HTML-tidy meddleware plugin that strips
> whitespace out of the HTML response (we are VERY generous with whitespace
> there :-)). During that process a few questions about how meddleware works
> popped up. So here go my question:
>
> 1)
> This is how we handle the request part:
>
>  # pass the request through our meddleware classes
>  for m in self.meddleware:
>     response = m.process_request(request, controller)
>     if response is not None:
>         return response(environ, start_response)
>
> So as soon as a single meddleware claims to handle the request, we stop
> parsing them through the others. Is this really what's intended here? AFAIK
> django hands requests through meddlewares, and hands the responses through
> all meddlewares in reverse order.

Django also short-circuits *request* middleware -- as soon as one
piece of request middleware returns something other than None, no more
are executed. But you're right, it then passes that through all of the
*response* middlewares in reverse order. There are three things that
I've seen trip people up about Django middleware:

1) request processing short-circuits, response does not
2) even if request processing short-circuits, *all* of the responses
are still executed in reverse order; this means you may have the
response side of your middleware executed when the request side has
not been
3) middleware instances are long-lived, so storing state on the
middleware about the request you're processing is a bad idea

So that's how Django handles it.  It looks like MG's implementation
doesn't call request meddleware if the response short-circuited. I'm
honestly not sure if that was a conscious decision or an oversight,
but I suspect the latter. Anyone have a conflicting opinion?

>
> 2) Our standard enabled meddlewares are "NoOp" and "CSRF". Calling a NoOp
> certainly doesn't hurt, but with all due respect are mediagoblins trying to
> accelerate climate change by burning CPU cycles? Why include the NoOp
> meddleware? I am sure there is a reason that I have overlooked.
>

I think I wrote NoOp as an example meddleware while we were working on
the initial implementation. It should definitely be removed from the
default list, and should probably be removed from the repo; it doesn't
add anything over BaseMeddleware.


NRY