Manlio Perillo ha scritto:
> Phillip J. Eby ha scritto:
>> [...]
>>> Note that some of these headers are response headers, and it is
>>> responsibility of the WSGI application to properly folding them, and not
>>> of the WSGI gateway.
>> On the contrary. The gateway is responsible for sending *all
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
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
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
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:
> 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
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
___
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
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
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
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
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
PJE wants to talk about WSGI 2. That's cool; I remind everyone that
there's a page to bring up issues you might want to discuss for 2.0:
http://wsgi.org/wsgi/WSGI_2.0
Feel free to add to, or discuss, issues on that page...
Ian
___
Web-SIG mailing
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
14 matches
Mail list logo
