On Oct 9, 2007, at 11:04 AM, Aleksey Midenkov wrote:
On Tuesday 09 October 2007 18:13:00 Nick Kew wrote:
On Tue, 9 Oct 2007 16:54:21 +0400
Aleksey Midenkov <[EMAIL PROTECTED]> wrote:
I believe the line making the connection always 'AP_CONN_CLOSE' on
force-response-1.0 is a erroneous leftover. The 1.0 should keep the
connection alive if the browser will ask it to do so.
httpd-trunk/modules/http$ grep -n -C 3 force-response-1.0
http_filters.c ...
700: /* kludge around broken browsers when indicated by
force-response-1.0 701- */
702- if (r->proto_num == HTTP_VERSION(1,0)
703: && apr_table_get(r->subprocess_env,
"force-response-1.0")) { 704- *protocol = "HTTP/1.0";
705- r->connection->keepalive = AP_CONN_CLOSE;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
706- }
...
Have you verified what happens if you remove that line?
Does it then respect exactly what the client asked for
if there's a Connection: header in the request?
And what does it then do if there isn't one?
Yes, I have checked all 6 variants. In case 'Connection:' header is
in the
request, the response is sent exactly how this header asks (for
both 1.0 and
1.1 protocols). In case of absence of 'Connection:' header, the
response for
1.0 answers with 'Connection: close' and closes the connection. The
response
for 1.1 does not have 'Connection:' header, but keeps the
connection open.
The logic is provided by ap_set_keepalive, it is called right after
basic_http_header_check in ap_http_header_filter. I believe the
absence of
the header in the last variant does regard RFC2616 (as 19.6.2 states).
I might be confused here, but if the response is forced 1.0,
then there are no keepalives in which case we want to *force*
keepalives off.
