Imho there is Pure and Unpure WSGI middleware, the former can be used or removed with zero change to the application, this works for things like:

- profiling - caching - csrf protection

This is what I think wsgi middleware should be.

Excellent rant. I have noticed the exact same problems with PSGI middleware. People end up with apps that depend on middleware that then depend on the app. This serves two purposes: making for a nice blog post about how generic you are (just implement these eight functions inside your app!), and adding bugs.

Just treat web programming like normal programming, and everything becomes simple!

I haven't done anything other than dabble with python in years and have never used WSGI, can someone point me to examples of this 'abuse' of WSGI in the wild? I'd love to get more background so I can really understand this post.

the author's argument is essentially that you shouldn't reach out to middleware from within your application code (e.g. sessions), but that such functionality should be provided by a non-middleware API, because you should be able to swap in/out middleware without any change to your app code.

are there examples of WSGI applications that provide sessions as middleware? just curious to see the approach in action.

I found Beaker, which looks pretty nice. http://beaker.groovie.org/index.html

this was written early 2007. do you guys / girls agree with the author?

I still agree.

Middleware can be effective for certain cross cutting situations (csrf checking and database transaction handling come to mind), but I think it's been applied to too many problems where it was completely unnecessary.

For example, user authentication in most web apps needs to be dealt with at the application level. Middleware based approaches like AuthKit and repoze.who end up relying on weird hacks to communicate between the authentication middleware and the application layer.I'm really not a fan of shuffling important application level data through random environment variables. Not to mention they're a massive pain in the ass to configure.

Note that for both csrf checking and database transaction handling, you still need hooks in place at your application level to be able to disable csrf checks or transactions in certain application specific situations, so it's not like you can just throw it into the middleware layer and forget about it.

Do you have a recommended session-handling API for a WSGI-based app (I'm not a framework such as Django)?

I'm currently looking at Beaker (http://beaker.groovie.org/index.html) but it is a middleware-based approach.

I think Beaker has been the Python standard for a while now (at least in non Django land). I would also recommend checking out Werkzeug in general, although its scope is a bit different than Beaker.

> you still need hooks in place at your application level to be able to disable csrf checks

Why would you want to disable the csrf check?

One example: for AJAX requests. From http://docs.djangoproject.com/en/dev/ref/contrib/csrf/#ajax

Most modern JavaScript toolkits send an "X-Requested-With: XMLHttpRequest" HTTP header; these requests are detected and automatically not handled by this [CSRF] middleware. We can do this safely because, in the context of a browser, the header can only be added by using XMLHttpRequest, and browsers already implement a same-domain policy for XMLHttpRequest.

Fair enough, but it doesn't mean your app requires hooks since the middleware can just not use CSRF if the x-requested-with header exists.