[Web-SIG] [extension] x-wsgiorg.flush
Phillip J. Eby
pje at telecommunity.com
Wed Oct 3 20:00:48 CEST 2007
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.
>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.
More information about the Web-SIG