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

[Graham Dumpleton]

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

Except that with the way that people use query strings to a GET
instead of a POST with form data in the body, that GET can technically
also have a content body, and how people in general abuse the method
type, that probably often isn't the case. This is why I was querying
the distinction, as not sure one can really say it is different to
other methods unless HTTP specifications do indicate as much at least
in relation to caching. Caching is an area I have never really looked,
so I don't really know what the specifications say so this could all
be irrelevant. :-)

Graham

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