[ZCM] [ZC] 1518/18 Comment "Zope 2.7.3b1 DAV server doesn't provide
DAV header"
Collector: Zope Bugs, Features,
and Patches ...
zope-coders-admin at zope.org
Fri Oct 8 04:26:00 EDT 2004
Issue #1518 Update (Comment) "Zope 2.7.3b1 DAV server doesn't provide DAV header"
Status Accepted, ZServer/bug critical
To followup, visit:
http://collector.zope.org/Zope/1518
==============================================================
= Comment - Entry #18 by ajung on Oct 8, 2004 4:25 am
If you want to work on a better solution than please commit
your changes before Sunday (10th, October) afternoon.
2.7.3 beta 2 will be released on 11th, October.
________________________________________
= Resubmit - Entry #17 by chrisw on Sep 30, 2004 5:35 pm
Status: Resolved => Accepted
Andreas, it's pretty rediculous to assign an issue to someone and then close it without giving them a chance to actually solve the damn thing!
What, exactly, have you done to re-instate DAV?
Just The DAV header or anything else?
Tres, there's no argument over re-instating the DAV header, I'm just trying to find the best way to do it. Your use case suggests a line in zope.conf is the way to go, I asked how best to implement that. I'm still searching for that answer...
As for high-handedness, there was a good period of time after I made the proposal in the collector for people to point out that this header is essential for DAV compliance, why did no-one speak up then?
Just to re-iterate, I WANT to solve this the RIGHT way. That MAY be the way that Andreas has already "solved" it, but I need to test it. Gimme a chance already!
________________________________________
= Resolve - Entry #16 by ajung on Sep 30, 2004 12:15 pm
Status: Accepted => Resolved
I reverted the removal of the DAV header for on the 2.7
branch and SVN trunk.
________________________________________
= Comment - Entry #15 by fenestro on Sep 30, 2004 12:04 pm
ok, tseaver points out a good reason to always return the DAV header. I am only looking at a small subset of the usage cases myself, so forget what I said about the conditional DAV header =)
________________________________________
= Comment - Entry #14 by fenestro on Sep 30, 2004 12:02 pm
I think it's probably reasonable to only send the DAV header if env['WEBDAV_SOURCE_PORT'] == 1. This appears to be set either if you're coming in on port 80 and are on the special list (eew), or if you're coming in on the configured webdav-source port.
(I don't know if the list of supported methods should also be reduced to GET, HEAD and POST in this case too)
________________________________________
= Comment - Entry #13 by tseaver on Sep 30, 2004 11:51 am
Unless somebody like Jim or Brian overrules, we *must*
restore the DAV: header for *all* HTTP access; the
"source port" is *not* the only legitimate locus for
doing DAV. Consider, for instance, the case where people
use DAV to manage collections of PDFs, images, etc., where "rendered" vs "non-rendered" is a meaningless distinction;
another case is using DAV to manage a bunch of "static"
HTML.
WRT "high-handedness": removing the header without
knowing its implications was already pretty "high-handed":
I know of *no* use case which is made better by the
absence of the 'DAV;" header, while we have ample evidence
that its absence causes harm.
Adding a knob to allow somebody to violate the standard
is *way* lower priority than restoring compliance.
________________________________________
= Comment - Entry #12 by fenestro on Sep 30, 2004 11:36 am
It's a list of compliance classes. If you're a DAV server at all, you at least return "1". Class 2 servers also support locking (LOCK method, supportedlock property, lockdiscovery property, Time-Out response header and Lock-Token request header; support for the Time-Out request header and owner XML element is suggested).
I suspect that ZServer couns as class 2; it supports the LOCK method, propnames in cadaver shows that it supports the supportedlock and lockdiscovery properties. I don't know the details of the implementation enough to say for sure.
________________________________________
= Comment - Entry #11 by chrisw on Sep 30, 2004 11:27 am
BTW, what I'd LIKE to see is an option in zope.conf to turn this on/off for a specific server.
For example, I think the "right" thing to do is to only have this header set for the source port server, and not for the other http ports.
However, I can already see people whining about this, so switches in zope.conf seem to be the right way to go about it.
How can this policy be implemented on a per-port basis?
________________________________________
= Comment - Entry #10 by chrisw on Sep 30, 2004 11:22 am
Andreas, I know you've got an axe to grind here, but quit being so hard nosed ;-)
I'm not arguing about the DAV header, I agree it needs to be re-instated, I'm just trying to find the best way to do that.
fenestro, in case you know the spec better than I do, what do the various possible values for the DAV header mean?
________________________________________
= Comment - Entry #9 by ajung on Sep 30, 2004 9:44 am
If the missing DAV header is breaking clients then
ChrisW's change for DAV header must be reverted. It is not
acceptable to break compatibility with webdav clients that worked until now.
________________________________________
= Comment - Entry #8 by fenestro on Sep 30, 2004 9:35 am
http://www.rfc-editor.org/rfc/rfc2518.txt
9.1 DAV Header
DAV = "DAV" ":" "1" ["," "2"] ["," 1#extend]
This header indicates that the resource supports the DAV schema and
protocol as specified. All DAV compliant resources MUST return the
DAV header on all OPTIONS responses.
If Zope stops returning the DAV header on OPTIONS (the only part I'm asking to be backed out), then it stops being a DAV complaint resource.
Just in case there's any ambiguity about what the word MUST means:
1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
definition is an absolute requirement of the specification.
________________________________________
= Comment - Entry #7 by chrisw on Sep 30, 2004 9:28 am
Nope. One report doesn't mean sudden reverting of a set of changes which eased things for a LOT of people.
It sounds like the DAV header may need to go back in, can someone point me at the spec so I can read up?
It might well end up being a config option in 2.8 ;-)
________________________________________
= Comment - Entry #6 by fenestro on Sep 30, 2004 9:27 am
FWIW, I support the removal of the Etag: and MS-whatever header. I just want to keep the DAV header that's actually a required part of the spec.
________________________________________
= Assign - Entry #5 by ajung on Sep 30, 2004 1:13 am
Chrisw: please revert the changes for 2.7.3 b2. I suggest
make your changes a configuration option in zope.conf for Zope 2.8 but this change seems to hurt more than it solves.
________________________________________
= Assign - Entry #4 by ajung on Sep 30, 2004 1:12 am
Status: Pending => Accepted
Supporters added: chrisw
Chrisw: please revert the changes for 2.7.3 b2. I suggest
make your changes a configuration option in zope.conf for Zope 2.8 but this change seems to hurt more than it solves.
________________________________________
= Comment - Entry #3 by fenestro on Sep 29, 2004 5:20 pm
After I readded the DAV: header (not the MS-whatever or Etag) by uncommenting the appropriate line in webdav/Resource.py's OPTIONS() function, my two clients were happy again.
________________________________________
= Comment - Entry #2 by Brian on Sep 29, 2004 4:04 pm
The DAV: header is part of the spec. I'm
not sure why it was pulled out, but I'd
bet that other clients will also break
as a result of it...
________________________________________
= Request - Entry #1 by fenestro on Sep 29, 2004 3:50 pm
When I upgraded from Zope 2.7.2 to 2.7.3b1, two of my DAV clients stopped working (cadaver continues to work). Using tcpdump to watch the responses shows that 2.7.3b1 is missing the DAV:, Ms-Author-Via: and Etag: headers that 2.7.2 reports. I suspect that DAV: is the crucial one that is causing my clients to report that it's not a DAV server.
Here is what 2.7.2 reported:
HTTP/1.0 200 OK
Server: Zope/(unreleased version, python 2.3.3, freebsd4) ZServer/1.1 Plone/2.0.3
Date: Wed, 29 Sep 2004 19:42:12 GMT
Content-Length: 0
Connection: close
DAV: 1,2
Ms-Author-Via: DAV
Connection: close
Etag:
Allow: GET, HEAD, POST, PUT, DELETE, OPTIONS, TRACE, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK
Date: Wed, 29 Sep 2004 19:42:12 GMT
And here is what 2.7.3b1 reports:
HTTP/1.0 200 OK
Server: Zope/(Zope 2.7.3b1-0, python 2.3.4, freebsd5) ZServer/1.1 Plone/2.0.3
Date: Wed, 29 Sep 2004 19:42:12 GMT
Content-Length: 0
Connection: close
Connection: close
Allow: GET, HEAD, POST, PUT, DELETE, OPTIONS, TRACE, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK
Date: Wed, 29 Sep 2004 19:42:12 GMT
These captures are available at http://rtg.ietf.org/~fenner/zope_dav_headers.html if the formatting in the bug report doesn't work out.
==============================================================
More information about the Zope-Collector-Monitor
mailing list