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

[Graham Dumpleton]

On 09/10/2007, Phillip J. Eby <pje at telecommunity.com> wrote:
> 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.

Why only a GET?

Just showing my ignorance here and would like it explained. :-)

Graham

> 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.  :)