On 09/10/2007, Phillip J. Eby <[EMAIL PROTECTED]> 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. :) _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com