At 07:03 PM 10/3/2007 +0200, Manlio Perillo wrote: >Phillip J. Eby ha scritto: > > Thinking about this made me realize that WSGI 2.0 isn't going to be able > > to validate *anything* about a response by raising an error in the > > application, because everything is done after the code returns. > > > >In this case, if the cache validation fails, we just have to generate >the body content. > >For which cases do you want to raise an exception?
Sorry, I thought you were talking about validating headers for *errors* (e.g. WSGI compliance problems), not providing special support for If-* headers. I don't think there's any point to having a WSGI extension for If-* header support. All the necessary data is in the environment, so it can trivially be implemented as a library or middleware, especially if the application postpones body content generation to an iterator. Since WSGI is intended to reduce web framework proliferation, one should never implement with middleware or a WSGI extension anything that can just be released as a library for others to use. > > That suggests to me that these sorts of errors should be handled by > > changing the response sent to the browser, instead. > >Right. >In this case Nginx, when the cache is fresh, should change the response >code from 200 (OK) to 304 (Not Modified). > >If I'm right, the current WSGI spec does not forbids or allows this. Actually, I was talking about handling the case of an invalid (ie. non-WSGI/HTTP compliant) header, not cache handling. Sorry for the confusion. _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
