[Web-SIG] [extension] x-wsgiorg.flush
Phillip J. Eby
pje at telecommunity.com
Tue Oct 9 03:10:50 CEST 2007
At 08:23 AM 10/9/2007 +1000, Graham Dumpleton wrote:
>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. :-)
Since GET is supposed to be side effect-free, skipping the
calculation of the response body (by not iterating over it) is less
likely to cause a problem than with another request method. I guess
HEAD would be safe, too.
If we were just now defining WSGI 1.0, I would let it be any method
and explicitly document that servers doing cache validation or
processing a HEAD method can skip iteration of the body, so that you
can get better performance.
However, if we put this language into WSGI 1.0, I'm wary of breaking
stuff that exists in the field; indeed it might be better just to say
that it's up to the user to add middleware to do this, rather than
trying to get a common standard for how servers should handle it.
More information about the Web-SIG