[ZCM] [ZC] 1441/22 Comment "Silly Borg Headers tempt MS Office"

Collector: Zope Bugs, Features, and Patches ... zope-coders-admin at zope.org
Sat Oct 2 05:03:13 EDT 2004 

Issue #1441 Update (Comment) "Silly Borg Headers tempt MS Office"
 Status Resolved, Zope/bug critical
To followup, visit:
  http://zope.org/Collectors/Zope/1441

==============================================================
= 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://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