On 25/01/2008, Brian Smith [EMAIL PROTECTED] 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,
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:
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
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
11 matches
Mail list logo
