You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Aleksey Midenkov <as...@uezku.kemsu.ru> on 2007/10/09 14:54:21 UTC
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
Posted by Aleksey Midenkov <as...@uezku.kemsu.ru>.
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;
Re: AP_CONN_CLOSE on force-response-1.0
Posted by Aleksey Midenkov <as...@uezku.kemsu.ru>.
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
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
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
Re: AP_CONN_CLOSE on force-response-1.0
Posted by Aleksey Midenkov <as...@uezku.kemsu.ru>.
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
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
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
Posted by Aleksey Midenkov <as...@uezku.kemsu.ru>.
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
Posted by Aleksey Midenkov <as...@uezku.kemsu.ru>.
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... :)
Re: AP_CONN_CLOSE on force-response-1.0
Posted by Jim Jagielski <ji...@jaguNET.com>.
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
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
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
Re: AP_CONN_CLOSE on force-response-1.0
Posted by Aleksey Midenkov <as...@uezku.kemsu.ru>.
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
Posted by Jim Jagielski <ji...@jaguNET.com>.
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
Posted by Aleksey Midenkov <as...@uezku.kemsu.ru>.
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
Posted by Rainer Jung <ra...@kippdata.de>.
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
Posted by Jim Jagielski <ji...@jaguNET.com>.
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=rev&revision=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
Posted by Aleksey Midenkov <as...@uezku.kemsu.ru>.
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=rev&revision=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
Posted by Jim Jagielski <ji...@jaguNET.com>.
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=rev&revision=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
Posted by Aleksey Midenkov <as...@uezku.kemsu.ru>.
On Tuesday 09 October 2007 22:49:38 Jim Jagielski wrote:
> http://svn.apache.org/viewvc?view=rev&revision=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
Posted by Jim Jagielski <ji...@jaguNET.com>.
http://svn.apache.org/viewvc?view=rev&revision=78967
That's a 1997 date, btw :)
Re: AP_CONN_CLOSE on force-response-1.0
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Oct 9, 2007, at 2:19 PM, Joshua Slive wrote:
> On 10/9/07, Jim Jagielski <ji...@jagunet.com> 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
Posted by Joshua Slive <jo...@slive.ca>.
On 10/9/07, Jim Jagielski <ji...@jagunet.com> 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
Posted by Jim Jagielski <ji...@jaguNET.com>.
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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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
Posted by Jim Jagielski <ji...@jaguNET.com>.
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
Re: AP_CONN_CLOSE on force-response-1.0
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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
Posted by Jim Jagielski <ji...@jaguNET.com>.
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 <as...@uezku.kemsu.ru> 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
Posted by Nick Kew <ni...@webthing.com>.
On Tue, 9 Oct 2007 19:04:22 +0400
Aleksey Midenkov <as...@uezku.kemsu.ru> 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
Posted by Aleksey Midenkov <as...@uezku.kemsu.ru>.
On Tuesday 09 October 2007 18:13:00 Nick Kew wrote:
> On Tue, 9 Oct 2007 16:54:21 +0400
>
> Aleksey Midenkov <as...@uezku.kemsu.ru> 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
Posted by Nick Kew <ni...@webthing.com>.
On Tue, 9 Oct 2007 16:54:21 +0400
Aleksey Midenkov <as...@uezku.kemsu.ru> 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/