On fre, 2008-07-04 at 15:43 +0200, Müller Johannes wrote:
To support more than one authentication method at a time we would have to do
fallback like AuthType Cert, Basic.
Or for that matter AuthType Digest, Basic.
Regards
Henrik
signature.asc
Description: This is a digitally signed message
On fre, 2008-05-30 at 11:06 +0200, Colm MacCárthaigh wrote:
Yep, Squid will delete all variations of an entity when you use
Accept: */*, that isn't easy with our current approach, but I'll see
what I can do - it would be nice.
Squid isn't quite that good on purging variants either..
Regards
On tor, 2008-05-15 at 21:00 +0200, Ruediger Pluem wrote:
\apache\src\log.c(682):apr_file_puts(errstr, logf);
I see nothing reasonable that we can do in this situation but ignoring the
error.
syslog?
Regards
Henrik
On tis, 2008-04-29 at 09:42 +0200, André Malo wrote:
Just to be exact - it *might* vary, depending on how no-gzip is set.
But then most likely not based on Accept-Encoding but other headers such
as User-Agent or the source IP...
In any event I fully agree that it's then the responsibility of
fre 2008-04-04 klockan 00:01 +0200 skrev Julian Reschke:
I think it's clear that a proxy that sees Expect: foobar will have to
immediately fail with status 417 if it doesn't know what foobar means.
Yes, that's a MUST level requirement in 14.20 Expect.. third paragraph,
and further clarified
On sön, 2008-01-06 at 01:20 +, Nick Kew wrote:
Do you mean as in tcpdump -x? I've uploaded a pair of dumps
(one of client-proxy, the other of proxy-server) at the same
location.
tcpdump -p -i any -s 1600 -w traffic.pcap port 80
Regards
Henrik
On sön, 2007-12-30 at 12:54 +0100, Werner Baumann wrote:
Is this true. Is there no way for a cache to uniquely identify variants,
but using the cache validator? Isn't this a flaw in the protocol?
The Content-Location also works as a variant identifier, but requires
that each variant do have a
On sön, 2007-11-11 at 12:44 +, Nick Kew wrote:
Note incoming c-l much earlier in the request processing cycle,
and use that for ap_http_filter? This would make sense for apps
that don't require c-l.
Except that you would then need to buffer the whole message to compute
the length..
On tis, 2007-10-16 at 18:26 +0200, jean-frederic clere wrote:
I though that a POST for a form returning Content-Type:
application/x-www-form-urlencoded must have a Content-length (and no
Transfer-Encoding: chunked). But I can't find this in any documentation
about it.
It's either
On fre, 2007-10-12 at 00:25 -0400, Chris Darroch wrote:
RFC 2616 section 14.24 (and 14.26 is similar) says, If the request
would, without the If-Match header field, result in anything other than a
2xx or 412 status, then the If-Match header MUST be ignored. Thus in
the typical case, if a
On ons, 2007-10-03 at 14:23 +0100, Nick Kew wrote:
http://issues.apache.org/bugzilla/show_bug.cgi?id=39727
We have some controversy surrounding this bug, and bugzilla
has turned into a technical discussion that belongs here.
Fundamental question: Does a weak ETag preclude (negotiated)
On ons, 2007-10-03 at 07:53 -0700, Justin Erenkrantz wrote:
As before, I still don't understand why Vary is not sufficient to
allow real-world clients to differentiate here. If Squid is ignoring
Vary, then it does so at its own peril - regardless of ETags.
See RFC2616 13.6 Caching Negotiated
On ons, 2007-10-03 at 13:29 -0700, Justin Erenkrantz wrote:
The issue here is that mod_dav_svn generates an ETag (based off rev
num and path) and that ETag can be later used to check for conditional
requests. But, if mod_deflate always strips a 'special' tag from the
ETag (per Henrik),
That
On ons, 2007-10-03 at 12:10 -0700, Roy T. Fielding wrote:
Two resource variants with different content-encoding is not
semantically equivalent as the recipient may not be able to understand
an variant sent with an incompatible encoding.
That is not true. The weak etag is for content
On ons, 2007-10-03 at 21:44 +0100, Nick Kew wrote:
The Cc: list on this and subsequent postings is screwed:
(1) It includes me, so I get everything twice.
OK, I can live with that, but it's annoying.
Use a Message-Id filter?
(2) It fails to include Henrik Nordstrom
On ons, 2007-10-03 at 23:52 +0200, Henrik Nordstrom wrote:
That is not HTTP. Don't confuse the needs of caching with the needs
of range requests -- only range requests need strong etags.
I am not. I am talking about If-None-Match, not If-Range. And
specifically the use of If-None-Match
On sön, 2007-09-30 at 16:54 -0700, Roy T. Fielding wrote:
On Sep 30, 2007, at 4:05 PM, Nick Kew wrote:
RFC2616 is clear that:
1. OPTIONS * is allowed.
2. OPTIONS can be proxied.
However, it's not clear that OPTIONS * can be proxied,
given that there's no natural URL
On ons, 2007-09-26 at 18:06 +0200, Nick Gearls wrote:
In the debug log, I can find:
Faking HTTP Basic Auth header: Authorization: Basic
L0M9QkUvU1Q9QmVsZ2l1bS9MPUJydXNzZWxzL089QXBwcm9hY2ggQmVsZ2l1bS9PVT1BcGFjaGUgdGVzdCBjZXJ0aWZpY2F0ZS9DTj0xMjcuMC4wLjE6cGFzc3dvcmQ=
What is this header
On tor, 2007-09-27 at 14:08 +0100, Joe Orton wrote:
From the name I'd presume these are testing a long chunk-extension, not
long chunks. There is no 2616 requirement to handle arbitrarily long
chunk-extensions so it's a meaningless test, unless httpd is not failing
appropriately. (the
On fre, 2007-09-21 at 11:06 -0400, Tom Donovan wrote:
Already-compressed data; like .jpg, .gif, .png, .zip, .tgz, .jar, and
any content filtered by mod_deflate are re-compressed. This uses
non-trivial CPU cycles for no (or slightly negative) benefit.
Bot yes and no. Unlike HTTP, SSL
On tis, 2007-09-18 at 22:41 +0200, Ruediger Pluem wrote:
Agreed. Depending on the answers above we may need to have a list of headers
(like Accept-Encoding) where we compare the tokens in the field-value.
For all other headers we would stay with the plain compare we do today.
See also the
On tis, 2007-09-18 at 19:40 +0200, Roy T.Fielding wrote:
Argued? The space does not change the value of the field (which is
a comma-separated list). The question is really up to us as to how
much effort we make to compare the values for equality, since the
non-match just makes our cache
Just wondering if there is any plans on addressing Bug #39727, incorrect
ETag on gzip:ed content (mod_deflate).
Been pretty silent for a long while now, and the current implementation
is a clear violation of RFC2616 and makes a mess of any shared cache
trying to cache responses from mod_deflate
On mån, 2007-08-27 at 13:09 -0400, Akins, Brian wrote:
On 8/27/07 12:34 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hasn't the non-compressed variant become an extreme edge-case
by now? I would certainly hope so.
Unfortunately not. About 30% of our requests do not advertise gzip
On mån, 2007-08-27 at 22:00 +0200, Ruediger Pluem wrote:
But without an adjusted conditional checking this leads to a failure
of conditional requests. And I currently do not see how we can adjust
ap_meets_conditions. As I understand 13.3.3 of RFC2616 the DEFLATE_OUT
filter transforms a
On sön, 2007-07-29 at 20:34 +0200, Graham Leggett wrote:
Niklas Edmundsson wrote:
The solution is to NOT rewrite the on-disk headers when the following
conditions are true:
- The body is NOT stale (ie. HTTP_NOT_MODIFIED when revalidating)
- The on-disk header hasn't expired.
- The
ons 2007-05-30 klockan 21:39 +0100 skrev Nick Kew:
It then proceeds to list HTTP status codes, and gives an errordocument
for each one. Unfortunately a number of them are bogus gibberish.
It's the gibberish Apache emits if you shoot yourself in the foot using
Redirect. Garbage in, garbage
tor 2007-05-24 klockan 13:22 +0200 skrev Niklas Edmundsson:
c) RFC-wise it seems to me that a not-modified object is a
not-modified object. There is no guarantee that next request will
hit the same cache, so nothing can expect a max-age=0 request to
force a cache to rewrite its
tis 2007-05-22 klockan 11:40 +0200 skrev Niklas Edmundsson:
-8---
Does anybody see a problem with changing mod_cache to not update the
stored headers when the request has max-age=0, the body turns out not
to be stale and the on-disk header hasn't expired?
mån 2007-04-16 klockan 22:58 +0200 skrev Ruediger Pluem:
My first question in this situation is: What is the correct thing to do here?
Generate the response from the cache (of course with the updated headers from
the 304
backend response) and delete the cache entry afterwards?
My
ons 2007-04-11 klockan 10:46 -0500 skrev William A. Rowe, Jr.:
Firefox is fine with...
ftp://[EMAIL PROTECTED]:[EMAIL PROTECTED]/
but it's odd enough I wouldn't trust that to be consistently supported,
and you raise a good point with proxy/firewalls.
The above isn't a correctly formed
lör 2007-04-07 klockan 04:00 -0500 skrev William A. Rowe, Jr.:
Of course this person is entirely wrong if the client doesn't
Accept-Encoding: chunked
which is exactly the logic we test.
So why is there a dependency on keep-alive being enabled?
Regards
Henrik
signature.asc
Description:
sön 2007-04-08 klockan 18:48 +0100 skrev Jay L. T. Cornwall:
So the part I'm leading up to is: how about a way to turn off these
warnings? Or perhaps a simple certificate analysis to see if the
wildcard matches all the virtual hosts for which it serves?
Sounds good to me.
Related to this,
lör 2007-04-07 klockan 09:18 +0200 skrev André Malo:
Hmm, you may get something wrong here. The httpd does apply chunked encoding
automatically when it needs to. That is in keep-alive situations without
given or determineable Content-Length.
Why doesn't it do it in all other cases? My
fre 2007-04-06 klockan 21:37 +0100 skrev Nick Kew:
What about modifying mod_ftp USER directive to accept username in the
format of [EMAIL PROTECTED], and tokenize user as the username, host as the
http-ish Host: virtual host name?
Sounds fair, provided the protocol doesn't assign some
ons 2007-04-04 klockan 13:12 +0200 skrev Julian Reschke:
What I meant by reason was the fact that the Destination header (and
some aspects of the If header) require absolute URIs, which is
problematic when there's a reverse proxy in the transmission path. All
the issues around to rewrite
mån 2007-02-12 klockan 12:41 +0200 skrev Dziugas Baltrunas:
To illustrate, squid for this purpose has reply_body_max_size [1]
parameter. Looks like it is only Content-Length response header (if
any) dependent,
It also terminates requests when the amount of data transferred hits the
specified
mån 2007-02-12 klockan 17:51 + skrev Nick Kew:
2. Where there's chunked encoding, the check would best be
implemented in the chunking filter.
3. A simple count/abort filter is then a last resort.
And it won't be able to tell the client what's happened,
because the header has already
mån 2007-02-12 klockan 21:55 + skrev Nick Kew:
Because the chunking filter is equipped to discard the chunk that
takes it over the limit, and substitute end-of-chunking.
If we do that in a new filter, we have to reinvent that wheel.
Not sure substitue end-of-chunking is a reasonable thing
tor 2007-02-08 klockan 17:15 -0800 skrev Devi Krishna:
Hi,
Resending this mail, just in case anyone would have
suggestions/inputs as how to fix this for connections that are in the
ESTABLISHED state or FIN state or any other TCP state other than
LISTEN
Maybe change the wake up call to
fre 2007-02-09 klockan 18:34 +0100 skrev Plüm, Rüdiger, VF EITO:
Not if BSD accept filters are in place. In this case the kernel waits until it
sees a HTTP request until it wakes up the process.
And on Linux with TCP_DEFER_ACCEPT enabled you need to sent a least one byte
of data.
So send
tor 2007-01-18 klockan 12:05 +0100 skrev Plüm, Rüdiger, VF EITO:
Just curious: Is the Unix epoch an invalid date in the Expires header
(as this in the past it does not really matter for the question whether
this document is expired or not as it would be in both cases)?
The RFC does not care
mån 2007-01-15 klockan 13:56 +0100 skrev Bart van der Schans:
In r463496 the following check was added to mod_cache.c :
else if (exp != APR_DATE_BAD exp r-request_time)
{
/* if a Expires header is in the past, don't cache it */
reason = Expires header already
lör 2007-01-13 klockan 01:06 +0100 skrev Ruediger Pluem:
This could be modified to:
1. Fix on trunk = Change state in Resolved, fixed and add a comment with
revision
of fix.
2. Proposed for backport = Leave state in Resolved, fixed and add a
comment with
revision of backport
ons 2006-12-13 klockan 08:51 -0500 skrev Brian Akins:
However, on an initial request (ie, non-conditional) we do not have an etag
from
the client, we only have info like Host, URI, Accept-*, etc. So, how would
the
cache identify which entity to serve in this case?
You have the URL and
tis 2006-12-12 klockan 09:20 -0500 skrev Brian Akins:
Only conditional requests from clients, generally, have If-None-Match
headers.
Correct. It's a conditional. These days you also see them from Squid
btw.
So the only way for a cache, on an initial request from a client, to
determine
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
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
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
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
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
tor 2006-12-07 klockan 02:31 +0100 skrev Justin Erenkrantz:
mod_deflate should just add the W/ prefix if it's not already there. --
justin
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
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-10-27 klockan 23:33 +0200 skrev Graham Leggett:
A second approach could involve the use of the Etags associated with
file responses, which in the case of files served off disk (as I
understand it) are generated based on inode number and various other
uniquely file specific
lör 2006-10-28 klockan 00:21 +0200 skrev Henrik Nordstrom:
fre 2006-10-27 klockan 23:33 +0200 skrev Graham Leggett:
A second approach could involve the use of the Etags associated with
file responses, which in the case of files served off disk (as I
understand it) are generated based
tor 2006-10-12 klockan 13:19 +0200 skrev Ruediger Pluem:
I do not think that this matters all too much, because the backend closes
the connection *immediately* after sending out the response.
To help this, perhaps there should be a check just before sending the
response as well, and send
tor 2006-09-21 klockan 12:18 +0200 skrev Plüm, Rüdiger, VF EITO:
IMHO this waits for a DoS to happen if the requestor can trick the backend
to get stuck with the request. So one request of this type would be sufficient
to DoS the whole server if the timeout is not very short.
How would this
tor 2006-09-21 klockan 00:19 +0300 skrev Issac Goldstand:
The only really relevant line I saw (in a quick 15 minute review) is RFC
2616-3.6 (regarding transfer-encodings):
Transfer-coding values are used to indicate an encoding
transformation that has been, can be, or may need to be
sön 2006-07-23 klockan 00:10 +0100 skrev Nick Kew:
But if you look at the full traceback and crossreference it to the
source, I think that looks improbable. Do you have sufficient gcc/gdb
expertise to shed real light on this?
Not really, only experience..
From what I have seen the causes to
lör 2006-07-22 klockan 18:00 +0100 skrev Nick Kew:
#3 0x08081d67 in ap_dbd_prepare (s=0x8daf5a0, query=0x Address
0x out of bounds, label=0x Address 0x out of
bounds)
at mod_dbd.c:150
Note: Could maybe be -O2 or higher optimizing away the variables when
tis 2006-07-18 klockan 00:47 +0200 skrev Ruediger Pluem:
And this is exactly the question: Is it ok for
the HEAD response to differ from the GET response with respect to T-E
and C-L headers
It's not in case of C-L. For a starter HEAD is used by quite many robots
with simplistic caches to
sön 2006-06-11 klockan 18:17 +0100 skrev Phil Endecott:
Is it possible that there is some libstdc++ initialisation that hasn't
happened? I could imagine that this would require special support from
the linker or the dlopen stuff, and that that behaves differently with
Sun's libc and
71 matches
Mail list logo
