[Zope-Coders] RFC: Remove funky WebDAV hackery?

[Casey Duncan]

If my less than perfect memory serves it was to solve problem specific to=
 MS=20
Office (Word mostly) saving repeatedly over to Zope via web folders.

The presence of these headers also cause another weird side-effect in off=
ice=20
or so I have heard. When downloading a Word doc on Windows from Zope from=
 a=20
browser, Word will see the DAV headers and think the user can save back t=
o=20
Zope over DAV. Somebody complained about this using software that generat=
ed=20
dynamic Word docs which obviously can't be saved.

At any rate sending these headers to all clients over the main HTTP port =
seems=20
silly. at a minimum they should be restricted to the DAV source port and=20
possibly limited only to specific clients. Although the latter should=20
probably be configurable.

I think a general mechanism for configuring headers of all kinds would be=
=20
quite nice. This could possibly just be some kind of reverse access rule =
that=20
can affect outgoing responses. A thought anyway. Adding more environment=20
variables for this seems icky.

-Casey

On Wednesday 07 August 2002 02:45 pm, Tres Seaver wrote:
> There are at least three places in the Zope2 source tree which make
> weird changes to the response object, presumably to support flaky
> Borg-ish clients.
>=20
>   ZServer/HTTPResponse.py -- injects an empty 'Etag:' header, if the
>     response hasn't set one explicitly.  This behavior is totally
>     unhelpful;  an empty Etag can't be used properly to do *anything*
>     that Etags are for;  I am guessing that some client (the way-brokey
>     WebFolders, perhaps?) won't do WebDAV unless an Etag is present?
>=20
>   lib/python/webdav/{Collection,Resource} -- 'dav__init'
>     sets a weird, custom header,'MS-Author-Via', to 'DAV';  again, I
>     presume this permits some flaky client to work well with the
>     object handling the request.
>=20
> The first change in particular is obnoxious;  some caches may refuse to
> cache pages with empty Etags, because they cannot be validated.  The
> second change could be less obnoxious if it was only done in the
> presence of the broken clients.
>=20
> Can anyone shed further light on this?
>=20
> Tres.
> --=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Tres Seaver                                tseaver@zope.com
> Zope Corporation      "Zope Dealers"       http://www.zope.com
>=20
>=20
> _______________________________________________
> Zope-Coders mailing list
> Zope-Coders@zope.org
> http://lists.zope.org/mailman/listinfo/zope-coders
>=20