mod_dav + Windows Web Folders problem

Breeze Howard <bhoward <at> fsu.edu>
2007-01-04 16:23:15 GMT

I have a Solaris 10 server with Apache 2.2.2 with mod_dav and related
modules compiled in it.
When we first started using mod_dav several months ago, it worked fine
with the Windows Web Folders, then recently, sometime around
mid-December, the mod_dav started exhibiting an odd behavior with
Windows Web Folders.
You can still login, you can upload folders that contain files, you can
get, delete and move files, you can overwrite existing files, but you
CAN'T upload new files. That's the only thing you can't do, and the only
client that can't do it is Windows Web Folders. And all of my users are
reporting this error on all of their webdav'ed directories. I have
replicated the errors on my Windows desktop running Windows XP Pro,
Version 2002, SP2.
Below is some output from the access_log file. The file was deleted
between clients, so as to show similar actions. Uploading a file
'pixel3.gif' into the /prospective Directory. In the first example with
WebDrive, I connect (OPTIONS, PROPFIND, PROPFIND, PROPFIND) and the I
upload the file (PUT, PROPFIND, PROPPATCH). Everything works, Yea! In
the second example with Windows XP Web Folders, I connect (OPTIONS,
OPTIONS, PROPFIND, PROPFIND), and I try to upload (HEAD). But it gives
me "An error occurred copying some or all of the selected files."
windows error and a "File does not exist" error in my Apache error_log.
I've included an excerpt from my httpd-dav.conf file below too, but
since it did not change, and I'm only having issues with one client, I
don't think that is my problem, unless something could be added to
BrowserMatch?

Re: mod_dav + Windows Web Folders problem

Joe Feise <jfeise <at> feise.com>
2007-01-05 03:47:21 GMT

Breeze Howard wrote on 01/04/07 08:23:
> I have a Solaris 10 server with Apache 2.2.2 with mod_dav and related
> modules compiled in it.
>
> When we first started using mod_dav several months ago, it worked fine
> with the Windows Web Folders, then recently, sometime around
> mid-December, the mod_dav started exhibiting an odd behavior with
> Windows Web Folders.
Hmm, a wild guess here: What version of IE is installed? The December Windows
Update installed IE7 by default on XP-SP2. That probably included a new version
of the webdav redirector.
It would be helpful to have the server log the user-agent.
Cheers,
-Joe

Re: mod_dav + Windows Web Folders problem

Rüdiger Plüm <r.pluem <at> gmx.de>
2007-01-05 09:52:44 GMT

On 01/04/2007 05:23 PM, Breeze Howard wrote:
>
> When we first started using mod_dav several months ago, it worked fine
> with the Windows Web Folders, then recently, sometime around
> mid-December, the mod_dav started exhibiting an odd behavior with
> Windows Web Folders.
I guess you use Windows Update to keep your boxes uptodate. So I guess
one of these updates screwed your webdav redirector.
> 146.201.xx.xx - - [03/Jan/2007:16:13:10 -0500] "HEAD
> /prospective/pixel3.gif HTTP/1.1" 302 -
>
> [Wed Jan 03 16:13:10 2007] [error] [client 146.201.3.45] File does not
> exist:
> /u/web-accts/virthosts/rdstage/public_html/students/prospective/pixel3.gif
Hm. This is really strange. The file does not exist, but httpd responds with
a redirect. This looks like to me as if you have something like
ErrorDocument 404 http://www.somewhere.com/errorpage.html
in your httpd.conf.
Where do you get if you enter http://yourwebdavbox/prospective/pixel3.gif manually
in your browser (provided that pixel3.gif still does not exist).
Regards

Re: mod_dav + Windows Web Folders problem

Julian Reschke <julian.reschke <at> gmx.de>
2007-01-05 14:48:47 GMT

Joe Feise schrieb:
> Hmm, a wild guess here: What version of IE is installed? The December Windows
> Update installed IE7 by default on XP-SP2. That probably included a new version
> of the webdav redirector.
> It would be helpful to have the server log the user-agent.
The WebDAV redirector is an OS component; it doesn't ship with IE. The
*Webfolder* component comes with the OS and Office, but (AFAIK) not with
IE as well.
The simplest way to check is to look at the version numbers, see
<http://greenbytes.de/tech/webdav/webfolder-client-list.html> and
<http://greenbytes.de/tech/webdav/webdav-redirector-list.html> for details.
Best regards, Julian

Re: mod_dav + Windows Web Folders problem

Breeze Howard <bhoward <at> fsu.edu>
2007-01-08 16:42:41 GMT

Julian Reschke wrote:
> Joe Feise schrieb:
>> Hmm, a wild guess here: What version of IE is installed? The December
>> Windows
>> Update installed IE7 by default on XP-SP2. That probably included a
>> new version
>> of the webdav redirector.
>> It would be helpful to have the server log the user-agent.
>
I that the same wild guess at some point and I did try webDaving from a
desktop that did not have IE upgraded and was still running IE 6. I had
the same problems webDAVing from the computer with IE 6.
As for the user-agent. Apache is set to print "combined" format logs.
And I do see the user-agent is many of my access_log lines. Just not
from the webdav lines that I'd like to see the user-agent in.
Here's some examples, These are from a non-Windows web client doing
webDAV. And they were having trouble uploading for an entirely
different reason, that I was able to correct (.htaccess was disallowing
them). So, when they couldn't upload, they would get redirected to the
/error/404.html and you can see the user-agent in those lines.
146.201.xx.xx - xxxxxxxx [03/Jan/2007:13:55:36 -0500] "PROPFIND
/prospective/admissions/ HTTP/1.1" 207 12001
146.201.xx.xx - xxxxxxxx [03/Jan/2007:13:55:39 -0500] "PROPFIND
/prospective/admissions/Style/ HTTP/1.1" 207 2299
146.201.xx.xx - xxxxxxxx [03/Jan/2007:13:55:41 -0500] "PROPFIND
/prospective/admissions/online/ HTTP/1.1" 207 6588

Re: mod_dav + Windows Web Folders problem

Julian Reschke <julian.reschke <at> gmx.de>
2007-01-08 22:13:19 GMT

Breeze Howard schrieb:
> ...
> That explains the 302 then. I was wondering about it, as well. We do
> have the ErrorDocument specified in our httpd.conf. And when I go to
> the http://webdavbox/prospective/pixel3.gif (or https), I get redirected
> to the http://webdavbox/error/404.html. And that file exists. Looking
> at the example above from a different webDAV client that was unable to
> upload for different reasons, they got redirected to the /error/404.html
> document too.
> ...
Well, that's a bug in the server. Don't blame the client; it's doing The
Right Thing here.
> ...
Best regards, Julian

Re: mod_dav + Windows Web Folders problem

Julian Reschke <julian.reschke <at> gmx.de>
2007-01-09 20:34:04 GMT

Rüdiger Plüm schrieb:
>
> On 01/08/2007 11:13 PM, Julian Reschke wrote:
>> Breeze Howard schrieb:
>>> ...
>>> That explains the 302 then. I was wondering about it, as well. We do
>>> have the ErrorDocument specified in our httpd.conf. And when I go to
>>> the http://webdavbox/prospective/pixel3.gif (or https), I get
>>> redirected to the http://webdavbox/error/404.html. And that file
>>> exists. Looking at the example above from a different webDAV client
>>> that was unable to upload for different reasons, they got redirected
>>> to the /error/404.html document too.
>>> ...
>>
>> Well, that's a bug in the server. Don't blame the client; it's doing The
>> Right Thing here.
>
> Its neither a bug in the server nor in the client. It is a
missconfiguration
> of the server for DAV access. You MUST not use external error pages
within
> a webdav area.
I think I have to disagree. An "external error page" mechanism that
produces a 302 where a 404 is in place simply is broken. It may work as
intended in a browser, but that doesn't make it correct.
Best regards, Julian

Re: mod_dav + Windows Web Folders problem

Rüdiger Plüm <r.pluem <at> gmx.de>
2007-01-09 21:10:29 GMT

On 01/09/2007 09:34 PM, Julian Reschke wrote:
> Rüdiger Plüm schrieb:
>>
>> On 01/08/2007 11:13 PM, Julian Reschke wrote:
>>> Breeze Howard schrieb:
>>>> ...
>>>> That explains the 302 then. I was wondering about it, as well. We do
>>>> have the ErrorDocument specified in our httpd.conf. And when I go to
>>>> the http://webdavbox/prospective/pixel3.gif (or https), I get
>>>> redirected to the http://webdavbox/error/404.html. And that file
>>>> exists. Looking at the example above from a different webDAV client
>>>> that was unable to upload for different reasons, they got redirected
>>>> to the /error/404.html document too.
>>>> ...
>>>
>>> Well, that's a bug in the server. Don't blame the client; it's doing The
>>> Right Thing here.
>>
>> Its neither a bug in the server nor in the client. It is a
> missconfiguration
>> of the server for DAV access. You MUST not use external error pages
> within
>> a webdav area.
>
> I think I have to disagree. An "external error page" mechanism that
> produces a 302 where a 404 is in place simply is broken. It may work as
> intended in a browser, but that doesn't make it correct.
Sorry, but I respectfully disagree here. It is finally up to the business

Re: mod_dav + Windows Web Folders problem

Julian Reschke <julian.reschke <at> gmx.de>
2007-01-09 21:53:09 GMT

Rüdiger Plüm schrieb:
>> I think I have to disagree. An "external error page" mechanism that
>> produces a 302 where a 404 is in place simply is broken. It may work as
>> intended in a browser, but that doesn't make it correct.
>
> Sorry, but I respectfully disagree here. It is finally up to the business
> logic of your site how you define this situation. If you choose to use
> an external error document for 404 "not found" then you simply define
> your site in a way that it has no URI's that return "404 not found".
> Keep in mind that URI's and physical files are not needed to have
> a 1:1 match or any match at all in the business logic of a site.
Yes. But if a client wants to know whether a URI is mapped, it will
fail. A redirect to an error document is not the same thing as a 404.
What's the point in doing this?
> This might not work properly with webdav clients and thus is the wrong
> configuration in this situation as the expectations of results to
> certain requests (if a file on the server is physically not present
> it should respond with a 404 and if it is physically present it should
> respond with a 200) on client side do not match the business logic on the
> server side, but it is not broken in general or violates the RFC by any means.
Hm. Doesn't compute for me.
302 means (<http://greenbytes.de/tech/webdav/rfc2616.html#status.302>):
"The requested resource resides temporarily under a different URI. Since
the redirection might be altered on occasion, the client SHOULD continue
to use the Request-URI for future requests. This response is only