+1 Linux Debian 3.1 Sarge, Apache 2.0.54 (mpm-prefork), Python 2.3.5
+1 Linux Debian Sid, Apache 2.2.3 (mpm-worker), Python 2.3.5
+1 Linux Debian Sid, Apache 2.2.3 (mpm-worker), Python 2.4.4
+1 Linux Debian Sid, Apache 2.2.3 (mpm-worker), Python 2.5
+1 Linux Ubuntu 6.0.6, Apache 2.0.55
+1 Mac OSX (Darwin 8.8.1), Apache 2.2.3 (mpm-prefork), Python 2.4.2
I don't see any harm. It isn't lost after all if one wants to go back
in the
revision history and get it back. :-)
On 10/12/2006, at 3:04 AM, Jim Gallacher wrote:
I stupidly tagged a branch with the wrong name (3-3-0-bc1 instead
of 3-3-0b). Should I remove it or just let it slide?
Jim
+1 Fedora Core 5 (i386), Apache 2.2.2 (mpm-prefork), Python 2.4.3
+1 Linux Fedora Core 6, Apache 2.2.3 (mpm-prefork), Python 2.4.4
Jim Gallacher wrote:
The mod_python 3.3-0b tarball is available for testing. Hopefully
Nicolas will have a chance to create Windows installers for testing in
the next couple of days.
Here are the rules:
In order for a file to
Let me preface all comments by saying that I AGREE with BOTH
Roy and Henrik... If Apache is sending the same exact (strong)
ETag value for both a compressed and an identity variant of
the same entity... then, according to current RFC content,
that is broken behavior and it should be fixed.
You
On 12/09/2006 06:52 AM, Roy T. Fielding wrote:
The best solution is to not mess with content-encoding at all, which
gets us out of both this consistency problem and related problems
with the entity-header fields (content-md5, signatures, etc.).
That is why transfer encoding was invented
Ruediger Pluem wrote:
This leads to the wrong error message DNS lookup failure for: a few lines
later. Shouldn't we do a
return HTTP_INTERNAL_SERVER_ERROR;
in the case unlocking fails?
Ah. You're right about the re-use of 'err'. As far as what we
should return, that's a whole
On 12/9/06, Ruediger Pluem [EMAIL PROTECTED] wrote:
The existing filter needs to modify the ETag field value (and
any other entity-dependent values that we can think of) or be
removed as a feature. Weak etags are not a solution -- being able
to make range requests of large cached
On 12/9/06, Roy T. Fielding [EMAIL PROTECTED] wrote:
The best solution is to not mess with content-encoding at all, which
gets us out of both this consistency problem and related problems
with the entity-header fields (content-md5, signatures, etc.).
That is why transfer encoding was invented in
FYI I get them too as early as 2.2.3 if I build mods-enabled=most or all
Issac
Roy T. Fielding wrote:
This is a bit unsettling, especially since I neither need nor want
any database-backed auth.
==
[Thu Dec 07 13:49:44 2006] [notice] Digest: generating secret for digest
authent
I stupidly tagged a branch with the wrong name (3-3-0-bc1 instead of
3-3-0b). Should I remove it or just let it slide?
Jim
[EMAIL PROTECTED] wrote:
Author: jgallacher
Date: Sat Dec 9 07:43:41 2006
New Revision: 484999
URL: http://svn.apache.org/viewvc?view=revrev=484999
Log:
copied trunk to
The mod_python 3.3-0b tarball is available for testing. Hopefully
Nicolas will have a chance to create Windows installers for testing in
the next couple of days.
Here are the rules:
In order for a file to be officially announced, it has to be tested by
developers on the dev list. Anyone
On 12/09/2006 03:23 PM, Justin Erenkrantz wrote:
On 12/9/06, Ruediger Pluem [EMAIL PROTECTED] wrote:
Would the following patch address all your points for a CE mod_deflate
filter?
No - this patch breaks conditional GETs which is what I'm against.
Ok, to be honest my question was more
On 12/9/06, Ruediger Pluem [EMAIL PROTECTED] wrote:
Thanks for giving the pointer to ap_meets_conditions. So content compressed
by mod_deflate would not stand conditional requests based on ETags any longer.
That would be bad. Would it help if we simply unset the ETag in mod_deflate?
mod_filter
On 12/09/2006 07:02 PM, Justin Erenkrantz wrote:
On 12/9/06, Ruediger Pluem [EMAIL PROTECTED] wrote:
Thanks for giving the pointer to ap_meets_conditions. So content
compressed
by mod_deflate would not stand conditional requests based on ETags any
longer.
That would be bad. Would it help
--- httpd/httpd/branches/2.2.x/STATUS (original)
+++ httpd/httpd/branches/2.2.x/STATUS Sat Dec 9 06:14:27 2006
@@ -88,6 +88,7 @@
and minfrin's fix is better than mine.
Cumulative patch:
William A. Rowe, Jr. wrote:
--- httpd/httpd/branches/2.2.x/STATUS (original)
+++ httpd/httpd/branches/2.2.x/STATUS Sat Dec 9 06:14:27 2006
@@ -88,6 +88,7 @@
and minfrin's fix is better than mine.
Cumulative patch:
fre 2006-12-08 klockan 15:35 -0800 skrev Justin Erenkrantz:
As Kevin mentioned, Squid is only using the ETag and is ignoring the
Vary header. That's the crux of the broken behavior on their part.
If they want to point out minor RFC violations in Apache, then we can
play that game as well.
lör 2006-12-09 klockan 15:23 +0100 skrev Justin Erenkrantz:
See the problem here is that you have to teach ap_meets_conditions()
about this. An ETag of 1234-gzip needs to also satisfy a
conditional request when the ETag when ap_meets_conditions() is run is
1234. In other words,
lör 2006-12-09 klockan 19:02 +0100 skrev Justin Erenkrantz:
AIUI, many caches do not allow the response to be cached at all if it
doesn't have an ETag.
Most still caches it, but for example Mozilla has bugs vrt Vary handling
if there is no ETag and the conditions changes..
In the ideal
fre 2006-12-08 klockan 15:40 -0800 skrev Justin Erenkrantz:
I think we all (hopefully) agree that a weak ETag is ideally what
mod_deflate should add.
Please read RFC2616 13.6 Caching Negotiated Responses for an in-depth
description of how caches should handle Vary. And please stop lying
about
lör 2006-12-09 klockan 05:44 -0500 skrev [EMAIL PROTECTED]:
It's relevant to the extent that I think there are still some things
missing from the RFCs with regards to all this which is why a piece
of software like SQUID might be doing the wrong thing as well.
Ater reading the RFC on this
I need to use SSL's crypto lib functions to decrypt (using RSA) in another
module.
I see that I need to use the SSL_CTX and/or SSL structures to do this.
I assume that I don't call
SSL_CTX_new()
to get the SSL_CTX, it looks like one-time-only, and I assume it's already been
done since
Justin wrote...
No - this patch breaks conditional GETs which is what I'm against.
See the problem here is that you have to teach ap_meets_conditions()
about this. An ETag of 1234-gzip needs to also satisfy a
conditional request when the ETag when ap_meets_conditions() is run is
1234.
And please stop lying about Squid.
C'mon Henrik. No one is intentionally trying to LIE about Squid.
If you are referring to Justin quoting ME let me supply a big
fat MEA CULPA here and say right now that I haven't looked
at the SQUID Vary/ETag code since the last major release
and I DO NOT KNOW
On 12/9/06, Detmar Meurers [EMAIL PROTECTED] wrote:
+1 Mac OSX (Darwin 8.8.1), Apache 2.2.3 (mpm-prefork), Python 2.4.2
+1 FreeBSD 6.1, Apache 2.2.3 (mpm-prefork), Python 2.4.3,1
lör 2006-12-09 klockan 20:38 -0500 skrev [EMAIL PROTECTED]:
If you are referring to Justin quoting ME let me supply a big
fat MEA CULPA here and say right now that I haven't looked
at the SQUID Vary/ETag code since the last major release
and I DO NOT KNOW FOR SURE what SQUID is doing ( or
28 matches
Mail list logo
