[Web-SIG] [extension] x-wsgiorg.flush

[Phillip J. Eby]

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.