Re: AP_CONN_CLOSE on force-response-1.0
On Saturday 13 October 2007 02:21:17 Roy T. Fielding wrote: On Oct 12, 2007, at 12:25 AM, Aleksey Midenkov wrote: On Thursday 11 October 2007 21:57:21 Roy T. Fielding wrote: On Oct 11, 2007, at 12:55 AM, Aleksey Midenkov wrote: This is all irrelevant. No current installation should need any of those env variables set. They exist solely for working around old versions of old clients that no longer exist on the net. Not all... We need mod_proxy responding exactly with what protocol backend server sent. For this purpose we use force-response-1.0. Then you are violating the HTTP standard. Roy Why? RFC 2616, sec 3.1: Due to interoperability problems with HTTP/1.0 proxies discovered since the publication of RFC 2068[33], caching proxies MUST, gateways MAY, and tunnels MUST NOT upgrade the request to the highest version they support. The proxy/gateway's response to that request MUST be in the same major version as the request. Roy But our proxy is not caching. Thank you for the warning though!
Re: AP_CONN_CLOSE on force-response-1.0
On Thursday 11 October 2007 21:57:21 Roy T. Fielding wrote: On Oct 11, 2007, at 12:55 AM, Aleksey Midenkov wrote: This is all irrelevant. No current installation should need any of those env variables set. They exist solely for working around old versions of old clients that no longer exist on the net. Not all... We need mod_proxy responding exactly with what protocol backend server sent. For this purpose we use force-response-1.0. Then you are violating the HTTP standard. Roy Why?
Re: AP_CONN_CLOSE on force-response-1.0
On Wednesday 10 October 2007 23:44:03 Roy T. Fielding wrote: On Oct 10, 2007, at 7:08 AM, Aleksey Midenkov wrote: On Wednesday 10 October 2007 18:04:47 Jim Jagielski wrote: On Oct 10, 2007, at 9:38 AM, Aleksey Midenkov wrote: And resolution for those who will suffer can be SetEnvIf Request_Protocol HTTP/1.0 nokeepalive No unnecessary CPU processing for majority. Huh? You're adding another conditional that needs to be checked... And for most cases, where the protocol is 1.1, it would be a waste of time. For one installation from a million it is acceptable tradeoff. But I really doubt it will be necessary to anyone. This is all irrelevant. No current installation should need any of those env variables set. They exist solely for working around old versions of old clients that no longer exist on the net. Roy Not all... We need mod_proxy responding exactly with what protocol backend server sent. For this purpose we use force-response-1.0.
[PATCH] Re: AP_CONN_CLOSE on force-response-1.0
On Wednesday 10 October 2007 18:46:15 Jim Jagielski wrote:
Or how about leaving the vast majority of the public completely
unaffected and creating a new envvar for those who have problems
with the 10 year old implementation...
If, however, you come up with a complete patch, including docs,
that do what you'd like, I'd certainly (assuming it's a valid
patch) +1 it.
I'll prefer to remain of the same opinion. Thank You! Here is the patch. It is
really simple to be invalid... :)
Index: docs/manual/env.html.en
===
--- docs/manual/env.html.en (revision 583757)
+++ docs/manual/env.html.en (working copy)
@@ -252,6 +252,12 @@
implemented as a result of a problem with AOL's proxies. Some
HTTP/1.0 clients may not behave correctly when given an HTTP/1.1
response, and this can be used to interoperate with them./p
+
+ div class=warning
+ pFor some time the behaviour of this variable was to disable
+ code class=directivea href=./mod/core.html#keepaliveKeepAlive/a/code for HTTP/1.0 responses.
+ Now it does not. To achieve such an effect code class=directivea href=./mod/mod_setenvif.html#setenvifSetEnvIf/a/code can be used on codea href=#nokeepalivenokeepalive/a/code variable./p
+ /div
Index: docs/manual/env.xml
===
--- docs/manual/env.xml (revision 583757)
+++ docs/manual/env.xml (working copy)
@@ -292,6 +292,14 @@
implemented as a result of a problem with AOL's proxies. Some
HTTP/1.0 clients may not behave correctly when given an HTTP/1.1
response, and this can be used to interoperate with them./p
+
+ note type=warning
+ pFor some time the behaviour of this variable was to disable
+ directive module=coreKeepAlive/directive for HTTP/1.0 responses.
+ Now it does not. To achieve such an effect directive module=
+ mod_setenvifSetEnvIf/directive can be used on codea href=
+ #nokeepalivenokeepalive/a/code variable./p
+ /note
/section
Index: CHANGES
===
--- CHANGES (revision 583757)
+++ CHANGES (working copy)
@@ -264,6 +264,9 @@
access control, as in: SSLRequire value in OID(1.3.6.1.4.1.18060.1)
[Martin Kraemer, David Reid]
+ *) HTTP protocol: removed disabling Keep-Alive for HTTP/1.0 when
+ force-response-1.0 is in effect. [Aleksey Midenkov asm ocslab.com]
+
[Apache 2.1.0-dev includes those bug fixes and changes with the
Apache 2.2.xx tree as documented, and except as noted, below.]
Index: modules/http/http_filters.c
===
--- modules/http/http_filters.c (revision 583757)
+++ modules/http/http_filters.c (working copy)
@@ -673,7 +673,7 @@
/*
* Determine the protocol to use for the response. Potentially downgrade
- * to HTTP/1.0 in some situations and/or turn off keepalives.
+ * to HTTP/1.0 in some situatuations.
*
* also prepare r-status_line.
*/
@@ -702,7 +702,6 @@
if (r-proto_num == HTTP_VERSION(1,0)
apr_table_get(r-subprocess_env, force-response-1.0)) {
*protocol = HTTP/1.0;
-r-connection-keepalive = AP_CONN_CLOSE;
}
else {
*protocol = AP_SERVER_PROTOCOL;
Re: AP_CONN_CLOSE on force-response-1.0
On Oct 11, 2007, at 12:55 AM, Aleksey Midenkov wrote: This is all irrelevant. No current installation should need any of those env variables set. They exist solely for working around old versions of old clients that no longer exist on the net. Not all... We need mod_proxy responding exactly with what protocol backend server sent. For this purpose we use force-response-1.0. Then you are violating the HTTP standard. Roy
Re: AP_CONN_CLOSE on force-response-1.0
On Tuesday 09 October 2007 22:49:38 Jim Jagielski wrote: http://svn.apache.org/viewvc?view=revrevision=78967 That's a 1997 date, btw :) There were no word about broken browsers in that commit, only about broken proxy. ;) On Tuesday 09 October 2007 22:41:19 Jim Jagielski wrote: I can't see changing the behavior now, after all these years. If we want to create a variant that maintains the feasibility of keepalives, then a big +1 for that, but it should be a new envvar, not changing the userland experience of an existing one... And if browser asks explicitly for Keep-Alive, why not to satisfy it? You should keep in mind that implicit behaviour is 'Connection: Close' for 1.0 protocol. I think, new envvar will add unnecessary complexity to configuration and redundant processing to servers...
Re: AP_CONN_CLOSE on force-response-1.0
On Oct 10, 2007, at 6:01 AM, Aleksey Midenkov wrote: On Tuesday 09 October 2007 22:49:38 Jim Jagielski wrote: http://svn.apache.org/viewvc?view=revrevision=78967 That's a 1997 date, btw :) There were no word about broken browsers in that commit, only about broken proxy. ;) On Tuesday 09 October 2007 22:41:19 Jim Jagielski wrote: I can't see changing the behavior now, after all these years. If we want to create a variant that maintains the feasibility of keepalives, then a big +1 for that, but it should be a new envvar, not changing the userland experience of an existing one... And if browser asks explicitly for Keep-Alive, why not to satisfy it? You should keep in mind that implicit behaviour is 'Connection: Close' for 1.0 protocol. I think, new envvar will add unnecessary complexity to configuration and redundant processing to servers... And I think changing the behavior of an existing envvar from how it's been used for ~10years is *sure* to create *more* confusion.
Re: AP_CONN_CLOSE on force-response-1.0
On Wednesday 10 October 2007 16:25:58 Jim Jagielski wrote: On Oct 10, 2007, at 6:01 AM, Aleksey Midenkov wrote: On Tuesday 09 October 2007 22:49:38 Jim Jagielski wrote: http://svn.apache.org/viewvc?view=revrevision=78967 That's a 1997 date, btw :) There were no word about broken browsers in that commit, only about broken proxy. ;) On Tuesday 09 October 2007 22:41:19 Jim Jagielski wrote: I can't see changing the behavior now, after all these years. If we want to create a variant that maintains the feasibility of keepalives, then a big +1 for that, but it should be a new envvar, not changing the userland experience of an existing one... And if browser asks explicitly for Keep-Alive, why not to satisfy it? You should keep in mind that implicit behaviour is 'Connection: Close' for 1.0 protocol. I think, new envvar will add unnecessary complexity to configuration and redundant processing to servers... And I think changing the behavior of an existing envvar from how it's been used for ~10years is *sure* to create *more* confusion. The behavior is wrong since 2001-03-16 and since then it *sure* made and keeps making confusion. About 6 years.
Re: AP_CONN_CLOSE on force-response-1.0
On Oct 10, 2007, at 8:38 AM, Aleksey Midenkov wrote: On Wednesday 10 October 2007 16:25:58 Jim Jagielski wrote: On Oct 10, 2007, at 6:01 AM, Aleksey Midenkov wrote: On Tuesday 09 October 2007 22:49:38 Jim Jagielski wrote: http://svn.apache.org/viewvc?view=revrevision=78967 That's a 1997 date, btw :) There were no word about broken browsers in that commit, only about broken proxy. ;) On Tuesday 09 October 2007 22:41:19 Jim Jagielski wrote: I can't see changing the behavior now, after all these years. If we want to create a variant that maintains the feasibility of keepalives, then a big +1 for that, but it should be a new envvar, not changing the userland experience of an existing one... And if browser asks explicitly for Keep-Alive, why not to satisfy it? You should keep in mind that implicit behaviour is 'Connection: Close' for 1.0 protocol. I think, new envvar will add unnecessary complexity to configuration and redundant processing to servers... And I think changing the behavior of an existing envvar from how it's been used for ~10years is *sure* to create *more* confusion. The behavior is wrong since 2001-03-16 and since then it *sure* made and keeps making confusion. About 6 years. Whatever. I would for sure wager that if this is changed, people will see a SLEW of incoming reports that Hey, I switched from 2.2.6 to 2.2.7 and I'm seeing this change... I am also sure that wrong or not, there are a lot of people who have either worked around this or are depending on it, and cutting them off at the knees with no workaround is hardly something responsible developers should do. I really don't care all that much, but I tend to recall that we have at least *some* responsibility to our userbase out there, and fixing something to help out one set, while at the same time ignoring the impacts on another set is foolish. BTW: The rev you refer to doesn't change the behavior of force- response-1.0 *itself* but rather when it's applied. So the fact that force- response-1.0 forcibly disables keepalives is something that's been with us for ~10 years.
Re: AP_CONN_CLOSE on force-response-1.0
On Wednesday 10 October 2007 16:55:03 Jim Jagielski wrote: On Oct 10, 2007, at 8:38 AM, Aleksey Midenkov wrote: The behavior is wrong since 2001-03-16 and since then it *sure* made and keeps making confusion. About 6 years. Whatever. I would for sure wager that if this is changed, people will see a SLEW of incoming reports that Hey, I switched from 2.2.6 to 2.2.7 and I'm seeing this change... I am also sure that wrong or not, there are a lot of people who have either worked around this or are depending on it, and cutting them off at the knees with no workaround is hardly something responsible developers should do. I really don't care all that much, but I tend to recall that we have at least *some* responsibility to our userbase out there, and fixing something to help out one set, while at the same time ignoring the impacts on another set is foolish. Of course it would be foolish. Actually there must be a sensible tradeoff between correctness and backward compatibility. And of course there must be an alternative for those who depend on wrong behaviour. I think in our case the quantity of those who wins from such behaviour is much smaller than of those who loses. In fact, I doubt that there will be numerous complaints if any will be at all. And resolution for those who will suffer can be SetEnvIf Request_Protocol HTTP/1.0 nokeepalive No unnecessary CPU processing for majority. I am sorry if my persistence can appear as a pressure to someone. But I really think this is the best solution. :)
Re: AP_CONN_CLOSE on force-response-1.0
On Wednesday 10 October 2007 18:04:47 Jim Jagielski wrote: On Oct 10, 2007, at 9:38 AM, Aleksey Midenkov wrote: And resolution for those who will suffer can be SetEnvIf Request_Protocol HTTP/1.0 nokeepalive No unnecessary CPU processing for majority. Huh? You're adding another conditional that needs to be checked... And for most cases, where the protocol is 1.1, it would be a waste of time. For one installation from a million it is acceptable tradeoff. But I really doubt it will be necessary to anyone.
Re: AP_CONN_CLOSE on force-response-1.0
On Oct 10, 2007, at 9:38 AM, Aleksey Midenkov wrote: And resolution for those who will suffer can be SetEnvIf Request_Protocol HTTP/1.0 nokeepalive No unnecessary CPU processing for majority. Huh? You're adding another conditional that needs to be checked... And for most cases, where the protocol is 1.1, it would be a waste of time.
Re: AP_CONN_CLOSE on force-response-1.0
On Oct 10, 2007, at 10:08 AM, Aleksey Midenkov wrote: On Wednesday 10 October 2007 18:04:47 Jim Jagielski wrote: On Oct 10, 2007, at 9:38 AM, Aleksey Midenkov wrote: And resolution for those who will suffer can be SetEnvIf Request_Protocol HTTP/1.0 nokeepalive No unnecessary CPU processing for majority. Huh? You're adding another conditional that needs to be checked... And for most cases, where the protocol is 1.1, it would be a waste of time. For one installation from a million it is acceptable tradeoff. But I really doubt it will be necessary to anyone. Or how about leaving the vast majority of the public completely unaffected and creating a new envvar for those who have problems with the 10 year old implementation... If, however, you come up with a complete patch, including docs, that do what you'd like, I'd certainly (assuming it's a valid patch) +1 it.
Re: AP_CONN_CLOSE on force-response-1.0
Aleksey Midenkov wrote: The behavior is wrong since 2001-03-16 and since then it *sure* made and keeps making confusion. About 6 years. If so (making confusion), we should see a long history of bugzilla tickets with an impressive CC list on them. Are there? This is not a rhethorical question, the answer might help to setlle the dispute. Regards, Rainer
Re: AP_CONN_CLOSE on force-response-1.0
On Oct 10, 2007, at 7:08 AM, Aleksey Midenkov wrote: On Wednesday 10 October 2007 18:04:47 Jim Jagielski wrote: On Oct 10, 2007, at 9:38 AM, Aleksey Midenkov wrote: And resolution for those who will suffer can be SetEnvIf Request_Protocol HTTP/1.0 nokeepalive No unnecessary CPU processing for majority. Huh? You're adding another conditional that needs to be checked... And for most cases, where the protocol is 1.1, it would be a waste of time. For one installation from a million it is acceptable tradeoff. But I really doubt it will be necessary to anyone. This is all irrelevant. No current installation should need any of those env variables set. They exist solely for working around old versions of old clients that no longer exist on the net. Roy
AP_CONN_CLOSE on force-response-1.0
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-}
...
Re: AP_CONN_CLOSE on force-response-1.0
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?
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
Re: AP_CONN_CLOSE on force-response-1.0
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).
Re: AP_CONN_CLOSE on force-response-1.0
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.
Re: AP_CONN_CLOSE on force-response-1.0
Jim Jagielski wrote: 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. Actually two different settings, no? 1.0 supported explicit keepalives.
Re: AP_CONN_CLOSE on force-response-1.0
On Tue, 9 Oct 2007 19:04:22 +0400 Aleksey Midenkov [EMAIL PROTECTED] wrote: Yes, I have checked all 6 variants. Nice - thanks. 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. OK, that last case is the one that risks biting us: if someone has asked the server to force a 1.0 response, that could be because there's a problem with keepalives (yes of course they can work around it, but we want to avoid breaking existing configs). On the basis of your analysis, I'd be +1 for checking the Connection header, and setting AP_CONN_CLOSE iff it doesn't ask for keep-alive. 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). Indeedie. But a forced 1.0 response is a workaround for agents that fail to support RFC2616 correctly, so that's not really the point. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: AP_CONN_CLOSE on force-response-1.0
Jim Jagielski wrote: On Oct 9, 2007, at 12:40 PM, William A. Rowe, Jr. wrote: Jim Jagielski wrote: 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. Actually two different settings, no? 1.0 supported explicit keepalives. But the force disabling is the main intent of the implementation, iirc. ie: they didn't behave right with Connection: Keep-Alive isn't there a connection-close variable trigger that should be used to enforce that?
Re: AP_CONN_CLOSE on force-response-1.0
On Oct 9, 2007, at 1:49 PM, William A. Rowe, Jr. wrote: Jim Jagielski wrote: On Oct 9, 2007, at 12:40 PM, William A. Rowe, Jr. wrote: Jim Jagielski wrote: 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. Actually two different settings, no? 1.0 supported explicit keepalives. But the force disabling is the main intent of the implementation, iirc. ie: they didn't behave right with Connection: Keep-Alive isn't there a connection-close variable trigger that should be used to enforce that? All I'm saying is that, iirc, the intent of force-response-1.0 is to force a 1.0 response and disable keepalives... it was designed to work around buggy browsers that had problems with 1.1 features, including wonky 1.0-type keepalives. If someone wants to create force-response-1.0-with-keepalives that does what force-response-1.0 does but allows for the potential of keepalives, then I'm fine with that. But changing how force-response-1.0 behaves is *sure* to cause problems for those who depend on the current behavior.
Re: AP_CONN_CLOSE on force-response-1.0
On 10/9/07, Jim Jagielski [EMAIL PROTECTED] wrote: All I'm saying is that, iirc, the intent of force-response-1.0 is to force a 1.0 response and disable keepalives... it was designed to work around buggy browsers that had problems with 1.1 features, including wonky 1.0-type keepalives. No, you are thinking of downgrade-1.0 or nokeepalive. force-response-1.0, according to the docs, is only supposed to change the response-line, and nothing else. It was specifically designed for stupid clients (AOL) that couldn't handle a response with HTTP/1.1 in the response line, even if only HTTP/1.0 features were used. See: http://httpd.apache.org/docs/2.2/env.html#special Joshua.
Re: AP_CONN_CLOSE on force-response-1.0
On Oct 9, 2007, at 2:19 PM, Joshua Slive wrote: On 10/9/07, Jim Jagielski [EMAIL PROTECTED] wrote: All I'm saying is that, iirc, the intent of force-response-1.0 is to force a 1.0 response and disable keepalives... it was designed to work around buggy browsers that had problems with 1.1 features, including wonky 1.0-type keepalives. No, you are thinking of downgrade-1.0 or nokeepalive. force-response-1.0, according to the docs, is only supposed to change the response-line, and nothing else. It was specifically designed for stupid clients (AOL) that couldn't handle a response with HTTP/1.1 in the response line, even if only HTTP/1.0 features were used. See: http://httpd.apache.org/docs/2.2/env.html#special Hasn't force-response-1.0 been disabling keepalives for *years*?? If I recall, again it's been awhile, the keepalive thing was a major part of the problem... I can't see changing the behavior now, after all these years. If we want to create a variant that maintains the feasibility of keepalives, then a big +1 for that, but it should be a new envvar, not changing the userland experience of an existing one... Just my 2c :)
Re: AP_CONN_CLOSE on force-response-1.0
http://svn.apache.org/viewvc?view=revrevision=78967 That's a 1997 date, btw :)
Re: AP_CONN_CLOSE on force-response-1.0
On Tuesday 09 October 2007 22:12, Jim Jagielski wrote:
All I'm saying is that, iirc, the intent of force-response-1.0 is
to force a 1.0 response and disable keepalives... it was designed
to work around buggy browsers that had problems with 1.1 features,
including wonky 1.0-type keepalives.
Actually, there is no problem to figure out from where the line had came
first:
httpd-1.3.x/src/main$ svn diff -r 78966:78967
Index: http_protocol.c
===
--- http_protocol.c (revision 78966)
+++ http_protocol.c (revision 78967)
@@ -1090,9 +1090,16 @@
if (!r-status_line)
r-status_line = status_lines[index_of_response(r-status)];
-if (r-proto_num == 1000
-table_get(r-subprocess_env,force-response-1.0))
+/* mod_proxy is only HTTP/1.0, so avoid sending HTTP/1.1 error
response; + * kluge around broken browsers when indicated by
force-response-1.0 + */
+if (r-proxyreq
+ || (r-proto_num == 1000
+table_get(r-subprocess_env,force-response-1.0))) {
+
protocol = HTTP/1.0;
+ r-connection-keepalive = -1;
+}
else
protocol = SERVER_PROTOCOL;
httpd-1.3.x/src/main$ svn log -r 78967 http_protocol.c
r78967 | fielding | 1997-08-15 21:59:52 +0400 (Fri, 15 Aug 1997) | 3 lines
Force proxy to always respond as HTTP/1.0, which it was failing to
do for errors and cached responses.
No word about buggy browsers in the comment. The r-proxyreq condition was
removed later, but keepalive assignment had left untouched.
On Thursday 15 March 2001 13:00, Graham Leggett wrote:
Hi all,
This patch stops the forced downgrade of the connection to HTTP/1.0 for
proxy requests.
Work is currently being done to ensure that mod_proxy is compliant with
HTTP/1.1 - the downgrade needs to go for this to work :)
Regards,
Graham
The patch was committed.
httpd-2.0/modules/http$ svn log -r 88528 http_protocol.c
r88528 | chuck | 2001-03-16 10:37:12 +0300 (Fri, 16 Mar 2001) | 4 lines
Stops the forced downgrade of the connection to HTTP/1.0 for proxy
requests. Submitted by: Graham Leggett
Reviewed by: Chuck Murcko
httpd-2.0/modules/http$ svn diff -r 88527:88528 http_protocol.c
Index: http_protocol.c
===
--- http_protocol.c (revision 88527)
+++ http_protocol.c (revision 88528)
@@ -770,12 +770,10 @@
if (!r-status_line)
r-status_line = status_lines[ap_index_of_response(r-status)];
- /* mod_proxy is only HTTP/1.0, so avoid sending HTTP/1.1 error
response; - * kluge around broken browsers when indicated by
force-response-1.0 + /* kluge around broken browsers when indicated by
force-response-1.0 */
- if (r-proxyreq
- || (r-proto_num == HTTP_VERSION(1,0)
- apr_table_get(r-subprocess_env, force-response-1.0))) {
+ if (r-proto_num == HTTP_VERSION(1,0)
+ apr_table_get(r-subprocess_env, force-response-1.0)) {
*protocol = HTTP/1.0;
r-connection-keepalive = -1;
