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

Phillip J. Eby pje at telecommunity.com
Mon Oct 8 21:32:48 CEST 2007

At 06:25 PM 10/8/2007 +0200, Manlio Perillo wrote:
>Phillip J. Eby ha scritto:
> > [...]
> >
> > I don't think there's any point to having a WSGI extension for If-*
> > header support.
>I have just found that the WSGI spec says:
>"""...it should be clear that a server may handle cache validation via
>the If-None-Match and If-Modified-Since request headers and the
>Last-Modified and ETag response headers."""
>So a WSGI implementation is *allowed* to perform cache validation, but
>it is not clear *how* this should be done.
>As an example, without the need of an extension, the start_response
>callable may check if Last-Modified or ETag is in the headers.
>In this case, it may perform a cache validation, and if the client
>representation is fresh, it may omit to send the body.
>However there are two problems here:
>1) It is not clear if WSGI explicitly allows an implementation to skip
>     the iteration over the app_iter object, for optimization purpose
>2) For a WSGI implementation embedded in an existing webserver, the
>     most convenient method to perform cache validation is to let the
>     server do it; however this requires to send the headers as soon as
>     start_response is called, and this is not allowed.

The only time that the headers can be changed is if there is an error 
during the generation of the body content.  So, the fact that 
send_headers() is called with a matching ETag or Last-Modified, is 
sufficient to determine that the request may be handled using a cache.

You are correct that the PEP does not explicitly allow the iteration 
to be skipped.  My thought is that it should indeed allow it, as long 
as the close() method (if any) is still called, and so long as the 
request method was a GET.

With that clarification added to the existing spec, I think it should 
be possible to implement cache validation in a server.

Hopefully, if anybody knows of a reason why this clarification should 
*not* be added to the spec, they will speak up now.  :)

More information about the Web-SIG mailing list