Would such patch (with errors fixed and documentation added) be accepted to
commit if made?
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
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
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
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
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
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
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
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
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
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
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.
And what if a large file is downloaded and processed by filters? Did the
buckets allocated by filters will not be deallocated until the connection
end? This can be a cause of DOS. The buckets should be freed after they have
flushed out of ap_core_output_filter.
On Friday 05 October 2007
Hello!
The bucket structure and the bucket contents live in different pools. The
bucket structure is allocated from bucket allocator (apr_bucket_alloc_t). So
my question is could the allocator pool cleanup chain get garbled if bucket
contents pool lifetime is shorter than the allocator pool
14 matches
Mail list logo
