Breeze Howard | 4 Jan 17:23 2007
Picon

mod_dav + Windows Web Folders problem

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?
(Continue reading)

Joe Feise | 5 Jan 04:47 2007

Re: mod_dav + Windows Web Folders problem

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

Rüdiger Plüm | 5 Jan 10:52 2007
Picon
Picon

Re: mod_dav + Windows Web Folders problem


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

(Continue reading)

Julian Reschke | 5 Jan 15:48 2007
Picon
Picon

Re: mod_dav + Windows Web Folders problem

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
Julian Reschke | 5 Jan 10:58 2007
Picon
Picon

Re: mod_dav + Windows Web Folders problem

Breeze Howard schrieb:
> Windows XP Web Folders:
> 146.201.xx.xx - - [03/Jan/2007:16:12:57 -0500] "OPTIONS / HTTP/1.1" 200 -
> 146.201.xx.xx - - [03/Jan/2007:16:12:57 -0500] "OPTIONS /prospective 
> HTTP/1.1" 200 -
> 146.201.xx.xx - bhoward [03/Jan/2007:16:12:58 -0500] "PROPFIND 
> /prospective HTTP/1.1" 207 833
> 146.201.xx.xx - bhoward [03/Jan/2007:16:12:58 -0500] "PROPFIND 
> /prospective HTTP/1.1" 207 11350
> 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
> ...

Why is the server replying with a 302 here?

Best regards, Julian
Breeze Howard | 8 Jan 17:42 2007
Picon

Re: mod_dav + Windows Web Folders problem

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
(Continue reading)

Julian Reschke | 8 Jan 23:13 2007
Picon
Picon

Re: mod_dav + Windows Web Folders problem

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
Julian Reschke | 9 Jan 21:34 2007
Picon
Picon

Re: mod_dav + Windows Web Folders problem

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

(Continue reading)

Rüdiger Plüm | 9 Jan 22:10 2007
Picon
Picon

Re: mod_dav + Windows Web Folders problem


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
(Continue reading)

Julian Reschke | 9 Jan 22:53 2007
Picon
Picon

Re: mod_dav + Windows Web Folders problem

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 
(Continue reading)


Gmane