WebDAV, Microsoft, DreamHost and the insane slash and pound hack

You know you're a geek when this kind of thing just drains your spirits.

It's the sheer stupidity of it -- on so many levels.

Mostly it's Microsoft's stupidity, but DreamHost deserves a whack as well.

For weeks I've been unable to connect to one of my DreamHost WebDav servers from XP machines. Works from OS X, not XP.

When I try from XP I get a windows SMB-style authentication dialog. I enter the un and password and get another version of the same dialog, but this one has a domain-authentication style username -- like ww.faughnan.com/username (yes, ww, not www).

The un/pw won't work, I just keep returning to the same dialog.

Finally, today, I worked my way through DreamHost's exceedingly annoying wiki documentation and found this little clause buried away:

WebDAV How-To Access - DreamHost

... Make this very 'important adjustment' to the file path: add the slash/ and pound# to the end of your path 'without quotes' like this: ' /# ' ...

Doesn't that just drain the life from ya? Buried away in the wiki? So incredibly obscure -- an obvious hack ...

So it works. When I enter my webdav address as http://www.faughnan.com/sillyservername/# the authentication succeeds.

So where the hell does this come from? You can't do a Google search on "/#" so I tried "slash pound XP webdav" and found this kind guidance (the old document refers to XP Home as though only it had this problem, but I use XP Pro):

You cannot access a WebDAV Web folder from a Windows XP-based client computer

WebDAV and the Troubled "Microsoft Way" of Implementation

... Misleading "feature" 298353: Add Network Place Wizard Saves the Location http:// as \\ in a Network Shortcut

... Workaround: use a port number after the domain, or use a trailing /. or a /# on any URL to use WebDAV properly in the setup wizard.
+ e.g.: http://www.atarex.com:80
+ e.g.: http://www.atarex.com/.
+ e.g.: https://www.atarex.com/#

... Explanation: the :port number on the domain name, the trailing slash dot "/.", or slash pound "/#" at the end of the URL prevents the bug which interprets the resource as a M$ network drive/SMB server

So this isn't the whole story but it's a hint.

More recently, there's this kb article which basically says "yeah, we know it's broken. Tough bunnies":

... This problem occurs when your users try to connect to a Web site whose address is something other than the root of the site....

... Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section of this article...

That led me back to this hidden 2004 DreamHost article from an old archive (I said DH deserved blame here). Turns out the problem is XP SP2 disabled BasicAuth (maybe for good reasons);

... After installing Service Pack 2 for Windows XP, you will no longer be able to connect to your account using WebDAV.

DreamHost uses BasicAuth (basic authentication) to verify your username and password when you connect to your account via WebDAV. Service Pack 2 for Windows XP disables support for BasicAuth.

You can enable BasicAuth in SP2 by adding the following registry key and setting it to a non-zero value:

HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\Services\WebClient\Parameters\UseBasicAuth (DWORD)

Reboot your machine, and WebDAV will begin working properly.

We are currently evaluating using options other than BasicAuth to resolve this issue. In the meantime, the workaround posted above will get the job done.

... comment: It is important to note that Microsoft disabled BasicAuth for a good reason. BasicAuth sends the username/password to the server in the clear, i.e. if someone is sniffing packets, they will be able to grab the password...

Ok, so this was disabled in 2004 for good reasons, but DreamHost still hasn't come up with a good solution?! They don't have a better authentication model?!

I'll report here whatever I get back from DreamHost -- including nothing.

Update: My DH support inquiry is tracking number: 2718630.

Update 10/10/08: DreamHost replied. It was an honest reply. Basically ...

• The support person admits the situation is not good, they'll push it up to the admin level.
• They liked the idea of a link from the webdav page to the supporting documentation
• WebDav hasn't been popular, so they haven't invested in it. (Of course that may be related to it not working as well.)
  
• Vista has the same problem.