[ZCM] [ZC] 1441/27 Comment "Silly Borg Headers tempt MS Office"
Collector: Zope Bugs, Features,
and Patches ...
zope-coders-admin at zope.org
Thu Dec 8 11:02:09 EST 2005
Issue #1441 Update (Comment) "Silly Borg Headers tempt MS Office"
Status Resolved, Zope/bug critical
To followup, visit:
http://www.zope.org/Collectors/Zope/1441
==============================================================
= Comment - Entry #27 by PatrickD on Dec 8, 2005 11:02 am
Just noticed that Microsoft Office 2003 needs the following registry keys to be able to edit file with WebDAV :
Create a DWORD value named OpenDocumentsReadWriteWhileBrowsing under HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Common\Internet and set it to 1.
Source: http://wiki.apache.org/jakarta-slide/WebFolderIssues
________________________________________
= Comment - Entry #26 by tseaver on Mar 29, 2005 2:01 pm
Note that we explicitly turned off that header for a reason.
Unless you can come up with a patch which makes the header
addition configurable, and off by default, we *won't* put it back.
Here is the checkin comment (from last fall):
Collector #1441: Removed headers introduced to make Microsoft
webfolders and office apps happy, since they make a lot of
standards-compliant things unhappy AND they trick MS Office
into trying to edit office files stored in Zope via WebDAV even
when the user isn't allowed to edit them and is only trying to
download them.
and the diff:
@@ -67,14 +67,13 @@
# Init expected HTTP 1.1 / WebDAV headers which are not
# currently set by the base response object automagically.
#
- # Note we set an borg-specific header for ie5 :( Also, we
- # sniff for a ZServer response object, because we don't
+ # Also, we sniff for a ZServer response object, because we don't
# want to write duplicate headers (since ZS writes Date
# and Connection itself).
if not hasattr(response, '_server_version'):
response.setHeader('Connection', 'close')
response.setHeader('Date', rfc1123_date(), 1)
- response.setHeader('MS-Author-Via', 'DAV')
+ # XXMSXX response.setHeader('MS-Author-Via', 'DAV')
# HTTP Range support
if HTTPRangeInterface.isImplementedBy(self):
________________________________________
= Comment - Entry #25 by PatrickD on Mar 29, 2005 11:15 am
The same patch applies to Zope 2.7.5-final.
________________________________________
= Comment - Entry #24 by PatrickD on Mar 21, 2005 6:16 am
With Zope 2.7.5RC1 on Win32, just applying the following patch make Microsoft Office 2003 Service Pack 1 happy with WebDAV :
$ diff Resource.py.orig Resource.py
76c76
< # XXMSXX response.setHeader('MS-Author-Via', 'DAV')
---
> response.setHeader('MS-Author-Via', 'DAV')
________________________________________
= Comment - Entry #23 by PatrickD on Jan 18, 2005 10:37 am
I just came across an detailed explanation of the "MS-Author-Via" tag: http://www-106.ibm.com/developerworks/rational/library/2089.html
Excerpt:
"""
Under the hood, Web Folders employ a programming interface called the OLE DB Provider for Internet Publishing (for information, visit msdn.microsoft.com/library/sdkdoc/ipubsdk/ipub01_8kf6.htm), which maps requests made via the user interface into network protocol requests. Web Folders use either the IETF standard WebDAV protocol or the Microsoft FrontPage protocol to send Web Folder requests across the network to a remote server. When a Web Folder first contacts a Web server, it goes through a discovery process to select which protocol to use.
The first step in the protocol discovery is sending an HTTP OPTIONS request, the standard feature-discovery mechanism for HTTP. If the response contains the MS-Author-Via header (a nonstandard header) with the value MS-FP/4.0, it will use the FrontPage protocol; if it has the value DAV, it will use the WebDAV protocol. If the MS-Author-Via header is not present, Web Folders loads the FrontPage protocol driver (called the Web Extender Client, or WEC), and asks it if it can talk to the server. It does this by sending a GET /_vti_inf.html, followed by a POST /_vti_bin/shtml.exe/_vti_rpc (the _vti is a leftover from FrontPage's early development by a startup called Vermeer Technology). If the server responds incorrectly (such as with a 404 Not Found message), Web Folders next checks for WebDAV support by sending a second OPTIONS request. This time, if the DAV (a header all WebDAV servers must implement) is present, Web Folders will begin using WebDAV."""
________________________________________
= Comment - Entry #22 by andrjohn on Oct 2, 2004 5:03 am
I can see from the history (e.g. http://mail.zope.org/pipermail/zope-dev/2001-November/014082.html) that the empty Etag was introduced to solve a read-only problem with Microsoft Word.
Looks like Windows uses the Etag header as part of their WebDAV lost-locking feature - it relies on an Etag that changes when the content of the resource changes - or more correct, when Windows expects it to change. An empty Etag does not change, so (I belive) that Windows will treat this as a lost WebDAV lock.
If I remove the empty Etag (from HTTPResponse.py), it looks like Word only uses LOCK, UNLOCK and locktoken for the locking feature. (Which I belive is correct behaviour since the Etag is not mandatory.) Now everything seems to work correct with Word 2003 and Zope.
So the old fix with the empty Etag made it incompatible with my version of "Microsoft Data Access Component Internet Publishing Provider" (msdaipp.dll version 11.0.5510.0) or some other Microsoft components (Windows XP, Office 2003 SP1).
Summary: Leaving out the empty Etag works for my installed versions of Windows XP and Office 2003.
________________________________________
= Comment - Entry #21 by fenestro on Sep 29, 2004 4:02 pm
I readded just the DAV: 1,2 header, not the MS-whatever-junk or Etag headers, and both MacOS X and sitecopy are happy again.
________________________________________
= Comment - Entry #20 by fenestro on Sep 29, 2004 3:55 pm
I can name two clients that don't work without a DAV: header: MacOS X's davfs, and sitecopy. See issue 1518.
________________________________________
= Comment - Entry #19 by tseaver on Sep 29, 2004 9:55 am
OPTIONS is a DAV-only method anyway; why shouldn't we
comply with the spec there? If complying with the DAV
spec (by including the header) causes some broken client
to choke, then tough; clients which don't speak DAV
won't be affected.
________________________________________
= Comment - Entry #18 by ajung on Sep 29, 2004 7:40 am
Are there any serious problems with exisiting DAV clients
when leaving out the header?
________________________________________
= Comment - Entry #17 by PatrickD on Sep 29, 2004 7:32 am
Uncommenting line 203 of Resource.py (from 2.7.3b1) solves this problem:
OPTIONS__roles__=None
def OPTIONS(self, REQUEST, RESPONSE):
"""Retrieve communication options."""
self.dav__init(REQUEST, RESPONSE)
RESPONSE.setHeader('Allow', ', '.join(self.__http_methods__))
RESPONSE.setHeader('Content-Length', 0)
- # XXMSXX RESPONSE.setHeader('DAV', '1,2', 1)
+ RESPONSE.setHeader('DAV', '1,2', 1)
RESPONSE.setStatus(200)
return RESPONSE
________________________________________
= Comment - Entry #16 by PatrickD on Sep 29, 2004 7:28 am
For record, my tests were done with Zope 2.7.3b1 and litmus 0.10.1 on Win32.
________________________________________
= Comment - Entry #15 by PatrickD on Sep 29, 2004 7:28 am
For the record, my tests were done with Zope 2.7.3b1 and litmus 0.10.1 on Win32.
________________________________________
= Comment - Entry #14 by PatrickD on Sep 29, 2004 7:26 am
Well, the "DAV: 1,2" header is part of the WebDAV specification for the OPTIONS command (paragraph 15.1 and 15.2 of http://www.ietf.org/rfc/rfc2518.txt). Removing it causes the WebDAV server protocol compliance test suite named litmus (http://www.webdav.org/neon/litmus/) to complain that the "server does not claim WebDAV compliance".
Best regards,
Patrick.
________________________________________
= Resolve - Entry #13 by chrisw on Jul 30, 2004 5:49 pm
Status: Accepted => Resolved
Now gone on 2.7 branch too, but just commented out, and a note put in CHANGES.TXT if people want to get them back.
These changes will land in Zope 2.7.3
________________________________________
= Edit - Entry #12 by chrisw on Jul 30, 2004 5:40 pm
Changes: submitter email, edited transcript, new comment
Tooo long on a bug day, need sleep...
________________________________________
= Comment - Entry #11 by chrisw on Jul 30, 2004 5:39 pm
Bingo. Spot on Chris. I debugged this but downloading an Excel file from Apache, and one from Zope and seeing what the difference was. These headers are it. Hack/patching them out as I have been for 2 years solves the problem with no ill effect.
PS: They're now gone in SVN and those changes will land in Zope 2.8 ;-)
________________________________________
= Comment - Entry #10 by mcdonc on Jul 30, 2004 5:07 pm
Er, I was never clear on how to fix this, but does what you're suggesting to fix have to do with this set of symptoms?:
http://www.plope.com/Members/chrism/ms_befuddled/view
________________________________________
= Comment - Entry #9 by chrisw on Jul 30, 2004 2:19 pm
This stuff IS going away, very shortly.
If M$ users are offended, they can add a add-broken-ms-headers switch to zope.conf and the appropriate code that only adds the broken headers when an incoming request from a broken MS client arrives.
________________________________________
= Comment - Entry #8 by ajung on Jul 30, 2004 5:39 am
see also #1368
________________________________________
= Comment - Entry #7 by ajung on Jul 30, 2004 12:43 am
As far as I can remember sending an ETAG is necessary
for make this M$ crap happy (which is important).
But I think it should only be send out on the webdav port
and not over the standard http port (so we need to add
a check for the outgoing port first).
In addition if you want sane HTTP header, you should add
an additional configuration option to zope.conf that removes any M$ specific headers...maybe the one you have
mentioned in your original posting.
Ok, we can discuss what the default behaviour should be (with or without M$ insane headers....I don't care). The default behaviour is known to the people but it is a bit insane to provide non-compliant behaviour by default. So maybe a switch "enable-all-my-microsoft-crap-headers" would be fine for me.
________________________________________
= Comment - Entry #6 by tseaver on Jul 29, 2004 10:06 am
Uploaded: "death-to-empty-Etag.patch"
- http://www.zope.org/Collectors/Zope/1441/death-to-empty-Etag.patch/view
While you are at it, scrub the "stuff an emtpy E-tag in
the response headers because some MS client thought it
needed one" hack.
Given the intended semantics of E-tags, an empty one is
*far* worse than an absent one, by any sane standard.
________________________________________
= Comment - Entry #5 by chrisw on Jul 28, 2004 4:47 pm
Well, I'd invite those users to come forward and try things out! Commenting out three lines of code and restarting Zope isn't a lot to ask.
What I'd LIKE to do (and was discussed in one of those threads below) is to add a knob in zope.conf that turns off ALL WebDAV on the main server port.
But, since I don't know how to do that from a how-the-f-is-webdav-wired-into-zserver point of view, I have the current plan.
Your suggestion of a knob just to disable these headers is a good one, and I'll do it IF users come forward who are relying on this functionality. Otherwise, deleting 3 lines of code is a MUCH easier prospect.
________________________________________
= Comment - Entry #4 by Caseman on Jul 28, 2004 4:38 pm
We need to account for users/applications that rely on Zope's compatibility with MS webfolders/office DAV. At a minimum that means testing functionality with and without the changes to determine what may be lost (if any). If there is a loss as a result, then I think we need to add a nob to zope.conf (which can be off by default) that turns on an MS compatibility mode which enables the existing behavior, or some variation thereof.
________________________________________
= Resubmit - Entry #3 by chrisw on Jul 28, 2004 4:30 pm
Status: Rejected => Accepted
Fine, well, to quote webdav.Resource.Resource:
# Note we set an borg-specific header for ie5 :( Also, we
The offensive headers are:
webdav/Resource.py - line 77:
response.setHeader('MS-Author-Via', 'DAV')
webdav/Resource.py - line 204:
RESPONSE.setHeader('DAV', '1,2', 1)
webdav/Collection.py - line 47:
response.setHeader('MS-Author-Via', 'DAV')
The symptoms are that anonymously accessible file objects storing things like Excel and Word documents pop up an MS Office auth box when accessed via IE on computers where MS Office is 2000 or above is installed.
Here's the tail of suffering:
http://mail.zope.org/pipermail/zope-coders/2002-January/000619.html
http://mail.zope.org/pipermail/zope/2002-January/106982.html
http://mail.zope.org/pipermail/zope-coders/2002-August/001648.html
http://mail.zope.org/pipermail/zope/2004-July/152055.html
I couldn't find my original post about the problem in 2001, I think it got eaten when the old collector died.
3 years of suffering is enough, like I said, provide compelling reasons for these headers to stay or they go on Friday.
________________________________________
= Reject - Entry #2 by Caseman on Jul 28, 2004 3:27 pm
Status: Accepted => Rejected
No offense Chris, but this is the vaguest critical bug I have yet experienced in the Zope collector. Please write a bug report that actually specifies what is wrong and what you think should be done to fix it.
I think I know what you are refering to, and I agree that what I think you are talking about should addressed. Please write a bug report that identifies the specific problem, preferably without offending an entire fictional civilization, regardless of how different their fictional ideals might be to ours (fictional or otherwise).
________________________________________
= Request - Entry #1 by chrisw on Jul 28, 2004 1:48 pm
Status: Pending => Accepted
Supporters added: chrisw
Several silly Borg headers are still being sent by Zope. I'm sick and tired of having to patch every release to get rid of this whenever I want to serve office files files to anymous users.
Unless I hear very compelling reasons to keep them, they're going in this Friday's bug day...
==============================================================
More information about the Zope-Collector-Monitor
mailing list