At 09:06 PM 12/17/2007 +0100, Manlio Perillo wrote:
>Phillip J. Eby ha scritto:
>>This is precisely why WSGI doesn't really have any "configuration"
>>defined, because the whole idea is that it should be as
>>"plug-and-play" as possible. Server-level configuration options
>>are a liability to b
Phillip J. Eby ha scritto:
> At 07:33 PM 12/17/2007 +0100, Manlio Perillo wrote:
> [...]
>
> And it's also irrelevant: WSGI applications are composable, which means
> that not only does the application deployer not necessarily have any
> idea what the application does, the *author* might not kno
At 07:33 PM 12/17/2007 +0100, Manlio Perillo wrote:
>Ian Bicking ha scritto:
> > [...]
> >
> > The user shouldn't have to anticipate what an application can or should
> > do, beyond what the spec says.
>
>I disagree.
>
>The intent of mod_wsgi for nginx, among other things, is to have an
>"integrate
Ian Bicking ha scritto:
> [...]
>
> The user shouldn't have to anticipate what an application can or should
> do, beyond what the spec says.
I disagree.
The intent of mod_wsgi for nginx, among other things, is to have an
"integrated" deployment platform for running WSGI applications;
so the
Manlio Perillo ha scritto:
> [...]
>
>> You should be able to detect whether interference is allowed based on
>> the response status, shouldn't you?
>
> Right.
>
>> That is, if there is a range
>> request and the application replies 200 OK, you can change that and
>> apply the ranges. But if
Manlio Perillo wrote:
>> That is, if there is a range request and the application replies 200
>> OK, you can change that and apply the ranges. But if the application
>> replies with 206 Partial Content then the range has already been
>> applied and the server shouldn't do anything to it.
>>
>
At 04:44 PM 12/17/2007 +, Chris Withers wrote:
>Manlio Perillo wrote:
> > 2) handle the range request in the WSGI application.
> >Its not hard as long as you do not implement multiple ranges support.
> >
> >If your object database supports seeks, this should be the most
> >efficient
Ian Bicking ha scritto:
> Manlio Perillo wrote:
>> Chris Withers ha scritto:
>>> Manlio Perillo wrote:
2) handle the range request in the WSGI application.
Its not hard as long as you do not implement multiple ranges
support.
If your object database supports seeks, t
Robert Brewer ha scritto:
> Chris Withers wrote:
>> Manlio Perillo wrote:
>>> 2) handle the range request in the WSGI application.
>>>Its not hard as long as you do not implement multiple ranges
>> support.
>>>If your object database supports seeks, this should be the most
>>>efficient
Manlio Perillo wrote:
> Chris Withers ha scritto:
>> Manlio Perillo wrote:
>>> 2) handle the range request in the WSGI application.
>>>Its not hard as long as you do not implement multiple ranges support.
>>>
>>>If your object database supports seeks, this should be the most
>>>efficien
Chris Withers wrote:
> Robert Brewer wrote:
> > Apache will interfere, and try to re-apply the range to whatever you
> > emit. The only solution we've found so far is to tell the app to
> ignore
> > any 'Range' request header when running behind Apache, and just let
> > Apache have its way. See htt
Robert Brewer wrote:
> Apache will interfere, and try to re-apply the range to whatever you
> emit. The only solution we've found so far is to tell the app to ignore
> any 'Range' request header when running behind Apache, and just let
> Apache have its way. See http://www.cherrypy.org/changeset/13
Chris Withers wrote:
> Manlio Perillo wrote:
> > 2) handle the range request in the WSGI application.
> >Its not hard as long as you do not implement multiple ranges
> support.
> >
> >If your object database supports seeks, this should be the most
> >efficient solution.
>
> This is pro
Chris Withers ha scritto:
> Manlio Perillo wrote:
>> 2) handle the range request in the WSGI application.
>>Its not hard as long as you do not implement multiple ranges support.
>>
>>If your object database supports seeks, this should be the most
>>efficient solution.
>
> This is proba
Manlio Perillo wrote:
> 2) handle the range request in the WSGI application.
>Its not hard as long as you do not implement multiple ranges support.
>
>If your object database supports seeks, this should be the most
>efficient solution.
This is probably what's wanted. So, if a wsgi app
15 matches
Mail list logo
