On 12.02.2010 10:58, rj...@apache.org wrote:
Author: rjung
Date: Fri Feb 12 09:58:48 2010
New Revision: 909323
URL: http://svn.apache.org/viewvc?rev=909323view=rev
Log:
Support remote https proxies by using HTTP CONNECT.
PR: 19188
Submitted by: Philippe Dutrueux lilas evidian.com
On Saturday 13 February 2010, Paul Querna wrote:
However, the newest reports have been about multiple browsers,
Firefox, Chrome, Safari, and IE8, all reporting the issue at the
same time. This makes be believe that the problem is something on
the server side.
I assume your mail here means
On 14.02.2010 16:09, minf...@apache.org wrote:
Author: minfrin
Date: Sun Feb 14 15:09:53 2010
New Revision: 910017
URL: http://svn.apache.org/viewvc?rev=910017view=rev
Log:
Introduce mod_reflector, a handler capable of reflecting POSTed
request bodies back within the response through the
This can't be the bug because it's in the input filter code,
but the most recent commit to mod_deflate.c has some UB in it
surrounding the case when readbytes is larger than what's available
in ctx-proc_bb. In that case bkt is the sentinel for ctx-proc_bb
and calling apr_brigade_split_ex looks
On 14.02.2010 17:19, Ruediger Pluem wrote:
On 12.02.2010 10:58, rj...@apache.org wrote:
Author: rjung
Date: Fri Feb 12 09:58:48 2010
New Revision: 909323
URL: http://svn.apache.org/viewvc?rev=909323view=rev
Log:
Support remote https proxies by using HTTP CONNECT.
PR: 19188
Submitted by:
But in mod_deflate.c in deflate_out_filter(), there is a check that
removes the filter if a Content-Range header is found. Why is
mod_deflate not removed from the output filter chain? Or is it the
intended order of the filters that mod_deflate compresses first and
the byterange filter
On 14 Feb 2010, at 6:55 PM, Ruediger Pluem wrote:
+/*
+ * We MUST read because in case we have an unknown-
length
+ * bucket or one that morphs, we want to exhaust it.
+ */
+status = apr_bucket_read(bucket,
