Phillip J. Eby ha scritto:
> [...]
> 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 t
2007/10/9, Graham Dumpleton <[EMAIL PROTECTED]>:
> On 09/10/2007, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> >
> > 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 requ
On 09/10/2007, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 08:23 AM 10/9/2007 +1000, Graham Dumpleton wrote:
> >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:
> > > > > [...]
> > > > >
> > > > >
At 08:23 AM 10/9/2007 +1000, Graham Dumpleton wrote:
>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-*
> >
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 s
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
Thomas Broyer ha scritto:
> 2007/10/8, Manlio Perillo:
>> 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 web
2007/10/8, Manlio Perillo:
> 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
2007/10/8, Manlio Perillo:
> 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-Mat
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 header
At 12:36 PM 10/5/2007 +0200, Manlio Perillo wrote:
>Phillip J. Eby ha scritto:
> > [...]
> > Yep, but another argument in favor of getting rid of as much
> > statefulness from the protocol as we can. Making the status and headers
> > part of the return value entirely eliminates the question of whe
Phillip J. Eby ha scritto:
> [...]
> Yep, but another argument in favor of getting rid of as much
> statefulness from the protocol as we can. Making the status and headers
> part of the return value entirely eliminates the question of when
> they're going to get written, and whether they can be
On 05/10/2007, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 09:03 AM 10/5/2007 +1000, Graham Dumpleton wrote:
> >Too early for me to be thinking straight and work it out for myself,
> >but does this all help in making it simpler or more obvious what the
> >cleanup requirements are for a generator
At 09:03 AM 10/5/2007 +1000, Graham Dumpleton wrote:
>Too early for me to be thinking straight and work it out for myself,
>but does this all help in making it simpler or more obvious what the
>cleanup requirements are for a generator. Ie., correct use of
>try/except/finally around yield and purpos
On 04/10/2007, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> >But once you have called start_response() you cant call it a second
> >time to change the values
>
> You can, as long as you pass in the exception info -- because an
> exception is the only legitimate reason to change the values.
Okay, fo
Phillip J. Eby ha scritto:
> At 06:07 PM 10/4/2007 +0200, Manlio Perillo wrote:
>> For nginx mod_wsgi I'm planning to add support to blocking
>> application,executing them in a thread (*but* there will be only one
>> thread per process, and the entire result will be buffered).
>>
>> Threaded execut
On Oct 4, 2007, at 11:55 AM, Phillip J. Eby wrote:
> At 05:00 PM 10/4/2007 +0200, Manlio Perillo wrote:
>> Your are making a critical decision here.
>> You are lowering the level of WSGI to match the level of average WSGI
>> middlewares programmers.
>
> No, we're just getting rid of legacy cruft
At 06:07 PM 10/4/2007 +0200, Manlio Perillo wrote:
>For nginx mod_wsgi I'm planning to add support to blocking
>application,executing them in a thread (*but* there will be only one
>thread per process, and the entire result will be buffered).
>
>Threaded execution will be disabled by default, and c
Phillip J. Eby ha scritto:
> [...]
>> I have read a lot of archived messages, and all I have seen are
>> *discussions* about asynchronous extensions, but no working
>> implementations.
>
> Because nobody came up with anything particularly useful. While it's
> possible to have generic extensions
At 05:00 PM 10/4/2007 +0200, Manlio Perillo wrote:
>Your are making a critical decision here.
>You are lowering the level of WSGI to match the level of average WSGI
>middlewares programmers.
No, we're just getting rid of legacy cruft that's hard to support
correctly. There's a big difference.
Phillip J. Eby ha scritto:
> At 04:10 PM 10/4/2007 +0200, Manlio Perillo wrote:
>> Graham Dumpleton ha scritto:
>> > [...]
>> >> The idea was to allow an application to change its mind about the
>> >> headers until it had committed to writing data. That is, to allow
>> >> the application to do err
Phillip J. Eby ha scritto:
> [...]
>
>> However I have to admit that developing a full asynchronous application
>> is not easy, notably when we have to interact with a database and a
>> transaction.
>
> Right - in practice, there is not enough of a common async API for
> Python to make it practic
At 04:10 PM 10/4/2007 +0200, Manlio Perillo wrote:
>Graham Dumpleton ha scritto:
> > [...]
> >> The idea was to allow an application to change its mind about the
> >> headers until it had committed to writing data. That is, to allow
> >> the application to do error handling for as long as possible
At 03:53 PM 10/4/2007 +0200, Manlio Perillo wrote:
>Phillip J. Eby ha scritto:
> > At 10:57 AM 10/4/2007 +0200, Manlio Perillo wrote:
> >> Phillip J. Eby ha scritto:
> >> > [...]
> >> >> There is a problem here: a WSGI gateway is not allowed to send headers
> >> >> until the app_iter yields a non e
Graham Dumpleton ha scritto:
> [...]
>> The idea was to allow an application to change its mind about the
>> headers until it had committed to writing data. That is, to allow
>> the application to do error handling for as long as possible before
>> the server has to do it.
>
> But once you have c
Phillip J. Eby ha scritto:
> At 10:57 AM 10/4/2007 +0200, Manlio Perillo wrote:
>> Phillip J. Eby ha scritto:
>> > [...]
>> >> There is a problem here: a WSGI gateway is not allowed to send headers
>> >> until the app_iter yields a non empty string or the iterator is
>> exausted.
>> >
>> > Argh.
At 10:20 PM 10/4/2007 +1000, Graham Dumpleton wrote:
>On 04/10/2007, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 12:30 PM 10/4/2007 +1000, Graham Dumpleton wrote:
> > >On 04/10/2007, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > > > At 09:52 PM 10/3/2007 +0200, Manlio Perillo wrote:
> > > > >T
On 04/10/2007, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 12:30 PM 10/4/2007 +1000, Graham Dumpleton wrote:
> >On 04/10/2007, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > > At 09:52 PM 10/3/2007 +0200, Manlio Perillo wrote:
> > > >There is a problem here: a WSGI gateway is not allowed to send
At 10:57 AM 10/4/2007 +0200, Manlio Perillo wrote:
>Phillip J. Eby ha scritto:
> > [...]
> >> There is a problem here: a WSGI gateway is not allowed to send headers
> >> until the app_iter yields a non empty string or the iterator is exausted.
> >
> > Argh. You're right. I forgot about that bit.
At 12:30 PM 10/4/2007 +1000, Graham Dumpleton wrote:
>On 04/10/2007, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 09:52 PM 10/3/2007 +0200, Manlio Perillo wrote:
> > >There is a problem here: a WSGI gateway is not allowed to send headers
> > >until the app_iter yields a non empty string or the
Phillip J. Eby ha scritto:
> [...]
>> There is a problem here: a WSGI gateway is not allowed to send headers
>> until the app_iter yields a non empty string or the iterator is exausted.
>
> Argh. You're right. I forgot about that bit. It has been a few too
> many years since I worked on the sp
On 04/10/2007, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 09:52 PM 10/3/2007 +0200, Manlio Perillo wrote:
> >Phillip J. Eby ha scritto:
> > > [...]
> > >
> > > Now that I understand what this is for, I can explain why a WSGI
> > > extension is not necessary to provide this feature. In a compli
At 09:52 PM 10/3/2007 +0200, Manlio Perillo wrote:
>Phillip J. Eby ha scritto:
> > [...]
> >
> > Now that I understand what this is for, I can explain why a WSGI
> > extension is not necessary to provide this feature. In a compliant WSGI
> > gateway, yielding an empty string from 'a-generator' is
Phillip J. Eby ha scritto:
> At 08:24 PM 10/3/2007 +0200, Manlio Perillo wrote:
>> WSGI already
>> states that the WSGI gateway should not buffer the data).
>
> It does not state that at all. It states that a gateway *must not delay
> the transmission of any block*. That requirement is not a "s
Phillip J. Eby ha scritto:
> [...]
>
> Now that I understand what this is for, I can explain why a WSGI
> extension is not necessary to provide this feature. In a compliant WSGI
> gateway, yielding an empty string from 'a-generator' is sufficient to
> "flush" the WSGI pipeline.
>
But the WSG
At 04:57 PM 10/3/2007 +0200, Manlio Perillo wrote:
>A possibile solution can be to add an extension `x-wsgiorg.flush`, a
>callable object that notify the WSGI gateway that it can flush the
>headers (if they are not yet be sent) or the output buffer (Nginx has
>this feature, however I have yet not u
At 08:24 PM 10/3/2007 +0200, Manlio Perillo wrote:
>WSGI already
>states that the WSGI gateway should not buffer the data).
It does not state that at all. It states that a gateway *must not
delay the transmission of any block*. That requirement is not a
"should" but a "must", and it does not d
Manlio Perillo ha scritto:
> [...]
> Note that in Nginx, unlike Apache, an output buffer can process a
> partial buffer,
Sorry, this is not correct.
The only difference from Apache, here, is that the data is written
asynchronously.
Manlio Perillo
___
Phillip J. Eby ha scritto:
> At 07:03 PM 10/3/2007 +0200, Manlio Perillo wrote:
>> Phillip J. Eby ha scritto:
>> > Thinking about this made me realize that WSGI 2.0 isn't going to be
>> able
>> > to validate *anything* about a response by raising an error in the
>> > application, because everythin
At 07:03 PM 10/3/2007 +0200, Manlio Perillo wrote:
>Phillip J. Eby ha scritto:
> > Thinking about this made me realize that WSGI 2.0 isn't going to be able
> > to validate *anything* about a response by raising an error in the
> > application, because everything is done after the code returns.
> >
Phillip J. Eby ha scritto:
> Thinking about this made me realize that WSGI 2.0 isn't going to be able
> to validate *anything* about a response by raising an error in the
> application, because everything is done after the code returns.
>
In this case, if the cache validation fails, we just hav
Thinking about this made me realize that WSGI 2.0 isn't going to be
able to validate *anything* about a response by raising an error in
the application, because everything is done after the code returns.
That suggests to me that these sorts of errors should be handled by
changing the response s
Hi.
Nginx, in one of the headers filters, can do ETag and Last-Modified
validation.
I want to be able to use this feature, so I don't have to use thirdy
party solutions.
However with the current WSGI implementation this is not possible.
A possibile solution can be to add an extension `x-wsgio
43 matches
Mail list logo
