Subject: MS Webfolder WebDAV Client: Authentication issue with handling of replies to PUT requests

From: Jim Whitehead <[email-masked]>
Date: Mon, 29 Jan 2007 09:03:22 -0800

Sending on behalf of Andy Staudacher <[email-masked]> (cc'ed). If  
you have any insight into these issues, please let Andy know.

- Jim

Hi

Problem:
Windows Webfolders does not show an authentication popup Window when the
server responds with a HTTP 401 to a PUT request although the response
includes a WWW-Authenticate header.

Questions:
1. Is this type of handling of PUT request replies a known issue for  
the MS
Webfolders WebDAV client?
2. Are there any workarounds?

Detailed problem description:
We have developed a PHP based WebDAV server (for gallery.sf.net) and  
we are
experiencing a problem with Microsoft's built-in WebDAV client  
(Microsoft
Webfolders, "Microsoft Data Access Internet Publishing Provider DAV").

Depending on how the server is configured, the client needs to  
authenticate
for specific requests.
By default any WebDAV client can connect to our WebDAV server and get a
listing of all folders / files without authentication. MKCOL and PUT
requests require authentication by default though.

Our WebDAV server implementation replies with a HTTP 401 'Authorization
Required' status with a WWW-Authenticate header to both requests  
(MKCOL and
PUT). While Windows Webfolders shows an authentication Window to the  
user
when receiving our response to a MKCOL request, it does not so for our
response to PUT a request.

All what the user sees when a PUT request fails with a HTTP 401 is a  
small
Window with a short, generic error message.

This is a major usability problem. Our end-users are usually not very
tech-savvy and thus rely on what is installed by default (MS Windows /
Windows Webfolders) and without being able to upload files, the WebDAV
components of our server doesn't make much sense.

Notes:
- Other clients (e.g. cadaver) work flawlessly with our WebDAV server.
- Client: Tested with Windows XP. Mounting / discovery is done via IE7
("Microsoft-WebDAV-MiniRedir/5.1.2600") and MKCOL/PUT requests are  
done via
Webfolders ("Microsoft Data Access Internet Publishing Provider DAV")
- Server: Apache2 / IIS + mod_php + Gallery 2.2 + Gallery WebDAV module

Some rather silly workarounds:
- Listing a virtual "login" folder which when requested always  
returns HTTP
401 with a WWW-Authenticate header.
- Requiring authentication for all operations, thus the client would  
have to
authenticate before it could even send a PUT request. (Unlikely to  
happen)
- (only for devs) Instructing the user to force authentication by always
creating a folder first. (Once authenticated, the authentication  
headers are
included in PUT requests as well.)

Of course we would prefer a solution that would simply trigger the
authentication popup of Windows Webfolders.

Thanks,
  - Andy Staudacher, Gallery.sourceforge.net developer

---

From: "Alex Jalali" <[email-masked]>
Date: Mon, 29 Jan 2007 12:20:35 -0800 (PST)

There are many issues with MS webfolders and if you want their
mini-redirector to work, it is even worst.

We've managed to get it to work with our i2drive.com server but with so
much headache. I hate them so much. if you work for MS you should kill
your self or something.

Anyway here are some things that may help.

1. get a tool called "nettool" or similar that lets you see and trace the
request/response to your server.

2. add the addHeader("MS-Author-Via", "DAV") in your response

4. MS may send the username as username@domain or username\domain
depending on how it feels like, so depending on if you want to use BASIC
or DIGEST authentication, you will need to extend the base Authenticator
and handle the username differently. Digest would be more difficult
becasue the digest send is based on that format of username.

5. if you use JDBCRealm then you will also have to extend that and deal
similar way.

6. another odd thing about mini redirector, and maybe webfolder too is
that the root can not be the starting point of the webdav

so it has to be http://domain/rootofyourwebdav/

It will ask for the / path with OPTION and at this point if you require
authentication it will not respond with any credentials and fails. but
still needs a ok response. after that when it asks for /webdav with
PROPFIND, etc... that's when you can send the WWW-Authenticator response

7. There are also bunch of issues related to the properties that it looks
for with the PROPFIND that you have to provide to it or it fails. such as
read-only etc. but i don;t remember them.

8. These links may also provide you with some information about their errors.

http://www.greenbytes.de/tech/webdav/webfolder-client-list.html
http://www.greenbytes.de/tech/webdav/webdav-redirector-list.html

---

From: "Andy Staudacher" <[email-masked]>
Date: Mon, 29 Jan 2007 22:24:57 +0100

Hi Alex,

Thanks for the tips. I'll make sure to address #4 (different username / auth
formats) once our HTTP-auth module supports Digest mode.

Too bad none of the tips help for the problem at hand.
I guess most WebDAV servers require auth for all operations and thus don't
have to deal with triggering auth in the Webfolders client on PUT requests.
Thus there are probably no well-known workarounds for this issue.

And yes, dealing with buggy system components is frustrating. :)

 - Andy

Alex Jalali wrote:
> There are many issues with MS webfolders and if you want 
> their mini-redirector to work, it is even worst.
> 
> We've managed to get it to work with our i2drive.com server 
> but with so much headache. I hate them so much. if you work 
> for MS you should kill your self or something.
> 
> 1. get a tool called "nettool" or similar that lets you see 
> and trace the request/response to your server.
> 
> 4. MS may send the username as username@domain or 
> username\domain depending on how it feels like, so depending 
> on if you want to use BASIC or DIGEST authentication, you 
> will need to extend the base Authenticator and handle the 
> username differently. Digest would be more difficult becasue 
> the digest send is based on that format of username.
> 
> 5. if you use JDBCRealm then you will also have to extend 
> that and deal similar way.
> 
> 6. another odd thing about mini redirector, and maybe 
> webfolder too is that the root can not be the starting point 
> of the webdav
> 
> It will ask for the / path with OPTION and at this point if 
> you require authentication it will not respond with any 
> credentials and fails. but still needs a ok response. after 
> that when it asks for /webdav with PROPFIND, etc... that's 
> when you can send the WWW-Authenticator response
> 
> 
> 7. There are also bunch of issues related to the properties 
> that it looks for with the PROPFIND that you have to provide 
> to it or it fails. such as read-only etc. but i don;t remember them.
> 
> > Windows Webfolders does not show an authentication popup 
> Window when 
> > the server responds with a HTTP 401 to a PUT request although the 
> > response includes a WWW-Authenticate header.
> >
> > Questions:
> > the MS Webfolders WebDAV client?
> > we are experiencing a problem with Microsoft's built-in 
> WebDAV client 
> > (Microsoft Webfolders, "Microsoft Data Access Internet Publishing 
> > Provider DAV").
> >
> > authenticate for specific requests.
> > By default any WebDAV client can connect to our WebDAV 
> server and get 
> > a listing of all folders / files without authentication. 
> MKCOL and PUT 
> > Our WebDAV server implementation replies with a HTTP 401 
> > 'Authorization Required' status with a WWW-Authenticate 
> header to both 
> > requests (MKCOL and PUT). While Windows Webfolders shows an 
> > authentication Window to the user when receiving our response to a 
> > MKCOL request, it does not so for our response to PUT a request.
> >
> > small Window with a short, generic error message.
> >
> > done via Webfolders ("Microsoft Data Access Internet Publishing 
> > Provider DAV")
> > - Listing a virtual "login" folder which when requested 
> always returns 
> > HTTP
> > have to authenticate before it could even send a PUT request. 
> > (Unlikely to
> > happen)
> > - (only for devs) Instructing the user to force authentication by 
> > always creating a folder first. (Once authenticated, the 
> > authentication headers are included in PUT requests as well.)
> >

---

From: "Andy Staudacher" <[email-masked]>
Date: Tue, 30 Jan 2007 02:03:56 +0100

Thanks for the hint. I guess your idea is that this specific client might
not expect the server to send the response before reading the complete
request.

Since our WebDAV server is a PHP script running on a webserver, we don't
have control over that though.
The PHP engine always reads the complete HTTP request before the script is
given control. If files are part of a HTTP request (POST, PUT), PHP stores
the file(s) on disk as temporary file(s), gives the script control to copy
them and once the script terminates, it deletes the temporary file(s) again.

So you might be onto something, but it would be exactly the other way
around. Maybe MS Webfolders expects a 401 response before the body is
transmitted. But that would be very, very weird to say the least.

(For the record, just to try all alternatives I moved the PHP's php://input
stream reading before the auth check to see if that helps. It didn't.)

Thanks for all your input,
 - Andy

Konstantin Breu wrote:
> One idea: 
> Maybe your server sends the 401 to the anonymous PUT request 
> without reading the HTTP body of the request (containing the 
> file). It could help to read the Http body before starting 
> the 401 response. Of course in this case the server does not 
> need to "know" the body, but it could help the client for the 
> further communication.
> 
> Cheers,
> Konstantin
>  
> -----Ursprüngliche Nachricht-----
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von Andy Staudacher
> Gesendet: Montag, 29. Januar 2007 22:25
> An: [email-masked]
> Betreff: RE: MS Webfolder WebDAV Client: Authentication issue 
> with handling of replies to PUT requests
> 
> 
> Hi Alex,
> 
> I guess most WebDAV servers require auth for all operations 
> and thus don't have to deal with triggering auth in the 
> Webfolders client on PUT requests.
> but with 
> > so much headache. I hate them so much. if you work for MS 
> you should 
> > kill your self or something.
> > 
> > depending on how it feels like, so depending on if you want to use 
> > BASIC or DIGEST authentication, you will need to extend the base 
> > Authenticator and handle the username differently. Digest would be 
> > more difficult becasue the digest send is based on that format of 
> > username.
> > 
> > 5. if you use JDBCRealm then you will also have to extend that and 
> > deal similar way.
> > 
> webfolder too is 
> > It will ask for the / path with OPTION and at this point if you 
> > require authentication it will not respond with any credentials and 
> > fails. but still needs a ok response. after that when it asks for 
> > /webdav with PROPFIND, etc... that's when you can send the 
> > WWW-Authenticator response
> > 
> > 
> > 7. There are also bunch of issues related to the properties that it 
> > looks for with the PROPFIND that you have to provide to it or it 
> > fails. such as read-only etc. but i don;t remember them.
> > 
> > 8. These links may also provide you with some information 
> about their 
> > errors.
> >

---

From: "Konstantin Breu" <[email-masked]>
Date: Mon, 29 Jan 2007 22:50:08 +0100

One idea: 
Maybe your server sends the 401 to the anonymous PUT request without reading
the HTTP body of the request (containing the file). It could help to read
the Http body before starting the 401 response. Of course in this case the
server does not need to "know" the body, but it could help the client for
the further communication.

Cheers,
Konstantin
 
-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im
Auftrag von Andy Staudacher
Gesendet: Montag, 29. Januar 2007 22:25
An: [email-masked]
Betreff: RE: MS Webfolder WebDAV Client: Authentication issue with handling
of replies to PUT requests

Hi Alex,

 - Andy

Alex Jalali wrote:
> about their errors.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 30 Jan 2007 14:29:46 +0100

> transmitted. But that would be very, very weird to say the least.

If the client sends the request with

	Expect: 100-continue

(see <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.8.2.3>), 
that would indeed the correct behavior. The problem is that this is very 
hard to implement in the generic case...

> Thanks for all your input,

Best regards, Julian