On Dec 8, 2006, at 8:07 AM, [EMAIL PROTECTED] wrote:
Author: jim
Date: Fri Dec 8 05:07:14 2006
New Revision: 483980
URL: http://svn.apache.org/viewvc?view=revrev=483980
Log:
Merge r442758 from trunk:
PR 31759 (mutated) - reported by Jo Rhett
Don't return apr_status_t error value from input
On 12/8/06, Henrik Nordstrom [EMAIL PROTECTED] wrote:
No, that won't work. You still be just as non-conforming by doing that.
But if mod_deflate may to produce different octet-level results on
different requests for the same original entity then it must do this in
addition to other transforms of
On 12/8/06, Henrik Nordstrom [EMAIL PROTECTED] wrote:
The protocol is quite fine as it is, and not easy to change. As it is
now it's mainly a matter of understanding that mod_deflate does create a
completely new entity from the original one. To the protocol it's
exactly the same as when using
fre 2006-12-08 klockan 14:47 +0100 skrev Justin Erenkrantz:
mod_deflate is certainly not creating a new resource
It is creating a new HTTP entity. Not a new object on your server, but
still a new unique HTTP entity with different characteristics from the
identity encoding.
If we were talking
fre 2006-12-08 klockan 14:40 +0100 skrev Justin Erenkrantz:
Uh, no, they *are* semantically equivalent - but, yes, not
syntactically (bit-for-bit) equivalent. You inflate the response and
you get exactly what the ETag originally represented.
To entities is only semantically equivalent if
tor 2006-12-07 klockan 02:42 +0100 skrev Justin Erenkrantz:
-1 on adding semantic junk to the existing ETag (and keeping it
strong); that's blatantly uncool. Any generated ETag from mod_deflate
should either be the original strong version or a weak version of any
previous etag. mod_deflate
fre 2006-12-08 klockan 14:40 +0100 skrev Justin Erenkrantz:
Uh, no, they *are* semantically equivalent - but, yes, not
syntactically (bit-for-bit) equivalent. You inflate the response and
you get exactly what the ETag originally represented.
To entities is only semantically equivalent if
Argh, my stupid ISP is losing apache email again because they use
spamcop.
On Dec 7, 2006, at 2:45 PM, Henrik Nordstrom wrote:
tor 2006-12-07 klockan 02:42 +0100 skrev Justin Erenkrantz:
-1 on adding semantic junk to the existing ETag (and keeping it
strong); that's blatantly uncool. Any
Following up on a question on the users list, I found this blog entry:
http://blogs.msdn.com/ie/archive/2006/10/17/accept-language-header-for-internet-explorer-7.aspx
which says that IE7 now uses only language/locale pairs in the
Accept-Language header.
They follow this up with:
If a given
In other words, Henrik has it right. It is our responsibility to
assign different etags to different variants because doing otherwise
may result in errors on shared caches that use the etag as a variant
identifier.
Henrik is trying to make it sound like it is all Apache's fault.
It is not.
Hello all,
I am currently looking into development for using httpd 2.2 as a
transparent reverse proxy. Something similar to squid+cttproxy in
reverse proxy mode. I wanted to check with the list to see if anyone
has looked into or done any development towards something similar to
this before I
fre 2006-12-08 klockan 15:03 -0500 skrev [EMAIL PROTECTED]:
To ONLY ever use ETag as a the end-all-be-all for variant
identification is, itself, a mistake.
Well, this area of the HTTP specs is pretty clear in my eyes, but then
I have read it up and down too many times unwinding the tangled
fre 2006-12-08 klockan 11:44 -0800 skrev Roy T. Fielding:
In other words, Henrik has it right. It is our responsibility to
assign different etags to different variants because doing otherwise
may result in errors on shared caches that use the etag as a variant
identifier.
Thanks ;-)
fre 2006-12-08 klockan 22:28 +0100 skrev Henrik Nordstrom:
A strong ETag must be unique among all variants of a given URI, that is
all different forms of entities that may reside under the URI and all
their past and future versions.
Forgot the last piece there which clears many doubts:
It always irked me that apxs -q {arbitraryvariable} throws up. Which ones
are valid anyways?
The attached patch would provide a list of the values from apxs -q
if no variable name is passed.
Feedback? If the list likes, please commit.
Bill
--- apxs 2006-07-15 06:25:47.0 -0500
+++
On 12/08/2006 10:37 PM, [EMAIL PROTECTED] wrote:
Author: jim
Date: Fri Dec 8 13:37:08 2006
New Revision: 484792
URL: http://svn.apache.org/viewvc?view=revrev=484792
Log:
Failure to unlock is very nasty, so log it to help
with troubleshooting.
Modified:
On Fri, 8 Dec 2006 16:25:01 -0500
Brian Rectanus [EMAIL PROTECTED] wrote:
Hello all,
I am currently looking into development for using httpd 2.2 as a
transparent reverse proxy.
How does a transparent reverse proxy differ from a reverse
proxy as we know and document it?
--
Nick Kew
fre 2006-12-08 klockan 22:04 + skrev Nick Kew:
How does a transparent reverse proxy differ from a reverse
proxy as we know and document it?
The Linux cttproxy patch allows proxies to be fully transparent
masquerading using the original clients source address on the
connections to the
On 12/8/06, Roy T. Fielding [EMAIL PROTECTED] wrote:
What we should be doing is sending transfer-encoding, not content-
encoding,
and get past the chicken and egg dilemma of that feature in HTTP.
If we are changing content-encoding, then we must behave as if there
are two different files on the
On 12/8/06, Henrik Nordstrom [EMAIL PROTECTED] wrote:
A strong ETag must be unique among all variants of a given URI, that is
all different forms of entities that may reside under the URI and all
their past and future versions.
A weak ETag may be shared by two variants/versions if and only if
On 12/8/06, Henrik Nordstrom [EMAIL PROTECTED] wrote:
fre 2006-12-08 klockan 22:04 + skrev Nick Kew:
How does a transparent reverse proxy differ from a reverse
proxy as we know and document it?
The Linux cttproxy patch allows proxies to be fully transparent
masquerading using the
Brian Rectanus wrote:
Yeah, sorry. Should have been a bit more verbose there ;)
I need client IP on the backend to deal with auth and logging. I
cannot always control the backend server or config, so not always
possible to work around it.
mod_rpaf works fine for me. It fixes the IP on the
On 12/8/06, Michael Cramer [EMAIL PROTECTED] wrote:
Brian Rectanus wrote:
Yeah, sorry. Should have been a bit more verbose there ;)
I need client IP on the backend to deal with auth and logging. I
cannot always control the backend server or config, so not always
possible to work around
On Dec 8, 2006, at 3:35 PM, Justin Erenkrantz wrote:
On 12/8/06, Roy T. Fielding [EMAIL PROTECTED] wrote:
What we should be doing is sending transfer-encoding, not content-
encoding,
and get past the chicken and egg dilemma of that feature in HTTP.
If we are changing content-encoding, then we
24 matches
Mail list logo
