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
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 application,
return
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, in the page
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, in the
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 /example/login.
My
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
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,
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 unquoted?
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 script
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 not iterate
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 work
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
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 is a GET
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 application to
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 output
18 matches
Mail list logo
