Creating strong Etags would be not to difficult, if the WebDAV
repository is only changed by mod_dav. To me it seems not very
important, how exactly the strong Etag is created:
(filesize+inode+counter, counter only, locking the file for one second,
enforcing an inode-change. All this can work.
Ruediger Pluem wrote:
http://svn.apache.org/viewcvs.cgi?rev=607245view=rev
Bill, is your vote conditional on changing this to the WARNING level or
can this be back ported as is?
Please back it down to WARN and it has my +1. DEBUG was much too quiet,
but this is not an ERR.
Bill
I've noted that the recent changes leave us unable to regenerate
a reliable piped log on win32 (perhaps we've been unable to for a
very long time, I'm not spinning my wheels to audit it but moving
forwards with its fix). I haven't checked if unix is affected,
but it's trivial to check (kill
William A. Rowe, Jr. wrote:
For information only; my post today based on new research into
Visual Studio 2008, and ActiveState Perl 5.10 binary release, over
these last few days.
Will focus the discussion on the [EMAIL PROTECTED] list for
now since it's most intricately affected (permalink)
Mladen Turk wrote:
Will focus the discussion on the [EMAIL PROTECTED] list for
now since it's most intricately affected (permalink)
IIUC, you are on the same track ;)
FYI - it would be more useful if you would post to [EMAIL PROTECTED],
Mladen, where ActiveState folk are already engaged in
While on the topic of ETags - I just picked up this regression in 2.2.7-dev
Some innocuous changes to make ETags always 64bit in modules/http/http_etag.c
broke DAV due to it's private dav_fs_getetag routine (ETags never matched
in ap_meets_condition due to the different format).
Patch below
Hi Joe,
thanks for your review and your detailed comments.
Commits containing changes authored by someone other than the committer
should have a Submitted by: line giving appropriate credit.
hmm, you mean with the SVN log? Sorry, forgot there - but it appears in CHANGES.
This patch
Michael Clark wrote:
Patch below makes mod_dav consistent with the format in http_etag.c
and fixes the cond_put regression with litmus
Index: modules/dav/fs/repos.c
===
--- modules/dav/fs/repos.c(revision 607400)
+++
From 2.2.x/STATUS:
* Various modules: Add explicit charset to the output of various
modules to work around possible cross-site scripting flaws affecting
web browsers that do not derive the response character set as required
by RFC2616.
Two comments on that: the first trivial, the second more
lör 2007-12-29 klockan 13:19 +0800 skrev Michael Clark:
AFAICT, we are in agreement here. My point was related to the current
inability to detect the direct filesystem access i.e. with the
DavETagIsolation dav+fs you would have to invalidate the ETag unless you
had some sort of mechanism
lör 2007-12-29 klockan 10:42 +0100 skrev Werner Baumann:
I have no idea what this would be. Can you give a *short* outline?
Please note: The weak Etags generated by Apache will *never* match. So
the only way I see, how Apache's weak Etags could be used, is to ignore
the weakness indicator,
Nick Kew wrote:
From 2.2.x/STATUS:
* Various modules: Add explicit charset to the output of various
modules to work around possible cross-site scripting flaws affecting
web browsers that do not derive the response character set as required
by RFC2616.
Two comments on that: the first
On Fri, 28 Dec 2007 19:56:27 +0100
Werner Baumann [EMAIL PROTECTED] wrote:
Although I think, I explained it on
http://issues.apache.org/bugzilla/show_bug.cgi?id=38034, here is a
summary again.
Thanks for the summary. It helps.
My Proposal:
Use the mod_dav-only patch as an
On 12/29/2007 06:22 PM, Nick Kew wrote:
From 2.2.x/STATUS:
* Various modules: Add explicit charset to the output of various
modules to work around possible cross-site scripting flaws affecting
web browsers that do not derive the response character set as required
by RFC2616.
Two
First:
I proposed to not only drop that *none*-Etag, but also to send no-cache.
The second is an error. The server should not send no-cache, but let it
to the client and the intermediate caches to decide about caching on the
base of the spec and their configured policy. But I still believe
On 12/29/2007 08:38 PM, [EMAIL PROTECTED] wrote:
Author: niq
Date: Sat Dec 29 11:38:51 2007
New Revision: 607466
URL: http://svn.apache.org/viewvc?rev=607466view=rev
Log:
mod_dav: Fix evaluation of If-Match * and If-None-Match * conditionals.
PR 38034
Patch by Paritosh Shah
[EMAIL PROTECTED] wrote:
Author: niq
Date: Sat Dec 29 11:50:11 2007
New Revision: 607468
URL: http://svn.apache.org/viewvc?rev=607468view=rev
Log:
Propose, veto.
Modified:
httpd/httpd/branches/2.2.x/STATUS
Modified: httpd/httpd/branches/2.2.x/STATUS
URL:
This is getting ridiculous. ETags are important to caching.
Caching is important to HTTP. If you sum up all of the instances
of webdav in the world (including the ones my company sells), they
still amount to nothing compared to the rest of the uses of HTTP.
If you want strong etags for
On Sat, 29 Dec 2007 20:43:39 +0100
Ruediger Pluem [EMAIL PROTECTED] wrote:
2. Might ISO-8859-1 be downright wrong in some instances?
Why should we suppose an FTP directory listing is ISO-8859-1?
I have a patch in the pipe that makes this configurable for
mod_proxy_ftp. But we thought
Hi --
I'm delighted to see that others have stepped in to keep this
thread going; thank you! Work commitments have kept me from having
the appropriate time to devote to it. It looks like Nick Kew and
Ruediger Pluem have committed some of the patches discussed in the
thread and the bug
I'm getting a segfault here in mod_dav from trunk (after a make clean)
running litmus using extras/httpd-dav.conf whereas it was working for me
last night. Not sure if this a work-in-progress. No time to file a bug
right now as i'm off for the weekend.
- running `locks':
0.
lör 2007-12-29 klockan 15:09 -0800 skrev Chris Darroch:
Reading that over, it still makes some sense to me. Apache httpd is
never in the situation implied by the RFC's example, where one wants to
generate a weak ETag because one has knowledge that the file's semantic
meaning hasn't
Michael Clark wrote:
I'm getting a segfault here in mod_dav from trunk (after a make clean)
running litmus using extras/httpd-dav.conf whereas it was working for me
last night. Not sure if this a work-in-progress. No time to file a bug
right now as i'm off for the weekend.
/* Set the
lör 2007-12-29 klockan 20:56 +0100 skrev Werner Baumann:
Objections:
- Squid seems not to take any information from the Etag.
Yes it does. It uses the ETag as an resource variant identifier.
- if the client has the etag and the entity (aka variant), it also has
the freshness information
24 matches
Mail list logo
