Hi.
I have implemented the wsgiorg.routing_args specification, using the
code in the example.
However I have a problem, and I can't see a good solution.
Suppose that an application is mounted (embedded in a web server) at
location "/example".
The application script executed by the server simp
At 03:22 PM 1/24/2008 +0100, Manlio Perillo wrote:
>Let's suppose that the request uri is "/example/login/".
>
>For the main application, SCRIPT_NAME is "/example".
>For the application at "/login", SCRIPT_NAME is "/example/login".
>
>My problem is that I want, in the page generated by "login" appl
Phillip J. Eby ha scritto:
> At 03:22 PM 1/24/2008 +0100, Manlio Perillo wrote:
>> Let's suppose that the request uri is "/example/login/".
>>
>> For the main application, SCRIPT_NAME is "/example".
>> For the application at "/login", SCRIPT_NAME is "/example/login".
>>
>> My problem is that I want
> Phillip J. Eby ha scritto:
> > At 03:22 PM 1/24/2008 +0100, Manlio Perillo wrote:
> >> Let's suppose that the request uri is "/example/login/".
> >>
> >> For the main application, SCRIPT_NAME is "/example".
> >> For the application at "/login", SCRIPT_NAME is "/example/login".
> >>
> >> My proble
Sven Berkvens-Matthijsse ha scritto:
>> Phillip J. Eby ha scritto:
>>> At 03:22 PM 1/24/2008 +0100, Manlio Perillo wrote:
Let's suppose that the request uri is "/example/login/".
For the main application, SCRIPT_NAME is "/example".
For the application at "/login", SCRIPT_NAME is
Ian Bicking wrote:
> We encountered it with GData too, as it uses URLs like
> /{http:%2f%2fexample.com}term/. But if you balance the {}'s
> you can parse it out.
Unquoted curly braces are illegal in any kind of URI or IRI. Does GData
really require them to be unquoted?
- Brian
__
My application correctly responds to HEAD requests as-is. However, it doesn't
work with middleware that sets headers based on the content of the response
body.
For example, a gateway or middleware that sets ETag based on an checksum,
Content-Encoding, Content-Length and/or Content-MD5 will all
I have applications that do detect the difference between a GET and a HEAD
(they
do slightly less work if the request is a HEAD request), so I suspect this is
not a totally reasonable thing to add to the spec. Maybe instead the
middleware
that does what you're describing should be changed ins
Brian Smith ha scritto:
> My application correctly responds to HEAD requests as-is. However, it doesn't
> work with middleware that sets headers based on the content of the response
> body.
>
> For example, a gateway or middleware that sets ETag based on an checksum,
> Content-Encoding, Content
Brian Smith wrote:
> Ian Bicking wrote:
>
>> We encountered it with GData too, as it uses URLs like
>> /{http:%2f%2fexample.com}term/. But if you balance the {}'s
>> you can parse it out.
>
> Unquoted curly braces are illegal in any kind of URI or IRI. Does GData
> really require them to be un
Brian Smith wrote:
> My application correctly responds to HEAD requests as-is. However, it
> doesn't work with middleware that sets headers based on the content
> of the response body.
>
> For example, a gateway or middleware that sets ETag based on an
> checksum, Content-Encoding, Content-Length
Manlio Perillo wrote:
> I have implemented the wsgiorg.routing_args specification, using the
> code in the example.
>
> However I have a problem, and I can't see a good solution.
>
> Suppose that an application is mounted (embedded in a web server) at
> location "/example".
>
> The application
On 25/01/2008, Brian Smith <[EMAIL PROTECTED]> wrote:
> 1. WSGI gateways must always set environ["REQUEST_METHOD"] to "GET" for HEAD
> requests. Middleware and applications will not be able to detect the
> difference between GET and HEAD requests.
>
> 2. For a HEAD request, A WSGI gateway must no
Chris McDonough wrote:
> I have applications that do detect the difference between a
> GET and a HEAD (they do slightly less work if the request is
> a HEAD request), so I suspect this is not a totally
> reasonable thing to add to the spec.
Yes, of course. In order to avoid doing unnecessary wo
Graham Dumpleton wrote:
> The issue here is that Apache has its own output filtering
> system where filters can set headers based on the actual
> content. Because of this, any output filter must always
> receive the response content regardless of whether the
> request is a GET or HEAD. If an ap
On 25/01/2008, Brian Smith <[EMAIL PROTECTED]> wrote:
> Graham Dumpleton wrote:
> > The issue here is that Apache has its own output filtering
> > system where filters can set headers based on the actual
> > content. Because of this, any output filter must always
> > receive the response content re
On 25/01/2008, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Brian Smith wrote:
> > Graham Dumpleton wrote:
> >> The issue here is that Apache has its own output filtering
> >> system where filters can set headers based on the actual
> >> content. Because of this, any output filter must always
> >> rece
Brian Smith wrote:
> Graham Dumpleton wrote:
>> The issue here is that Apache has its own output filtering
>> system where filters can set headers based on the actual
>> content. Because of this, any output filter must always
>> receive the response content regardless of whether the
>> request
Graham Dumpleton wrote:
> To quote, in 2 you said:
>
> """For a HEAD request, A WSGI gateway must not iterate
> through the response iterable"""
>
> I was presuming that this was saying that the WSGI gateway
> should do this as well as changing the REQUEST_METHOD
> actually sent to the WSGI ap
On 25/01/2008, Brian Smith <[EMAIL PROTECTED]> wrote:
> Graham Dumpleton wrote:
> > If Apache mod_wsgi (the WSGI gateway) does then do this, ie.,
> > didn't iterate through the iterable and therefore didn't
> > return the content through to Apache, it would as explained
> > cause traditional Apache
20 matches
Mail list logo
