It would be nice if Mozilla supported WebDAV like IE and KDE do. This means the ability to upload files from the browser (for sites using this instead of FTP for security), not just composer. A network abstraction layer might be appropriate since three applications want to use it (composer, calendar, and browser). There are plenty of other applications as well.

*** Bug 212341 has been marked as a duplicate of this bug. ***

i very much agree. i think this should be included asap. i dont like the fact that konqueror has such powerful features like webdav and mozilla doesnt ;-)

I've been working on a webdav library in JS. The DAV methods that extend HTTP (PROPFIND, PROPPATCH, LOCK, UNLOCK, MKCOL, etc.) aren't all that complicated on the client side. If you have good HTTP support, and a parser that can dive around inside namespaced XML pretty easily, then it's mostly a matter of reading the (well-written) spec and thinking about your implementation approach. But there's the rub. There are several ways this could be approached in Mozilla. You could take the approach done by xml-rpc, and have a component that you created an instance of and operate with. You could also model the server-side state as a client-side RDF datasource, mapping assertions to PROPPATCH requests. But this requires an RDF Zen level that I'm not up to.

Changing some metadata for this bug. This bug should be part of Firefox's future strategy. WebDAV is heating up. If WebDAV was supported by the browser, it would influence many corporations. Several intranet products have/are introducing the ability to manage assets via WebDAV. I've seen one or two already. Most 'extend' WebDAV on the client side (offering their own windows software to make use of their additions). If Firefox has the architecture to support WebDAV, these products can have their own FireFox extensions, and reach corporate users who don't want to be locked into a platform. WebDAV is perfered for corporate usage in intranets, because as companies try to lock down client workstations more (to prevent things like P2P and virus spreading) with Firewalls, Port 80 always remains... allowing WebDAV to be the method of choice. No extra ports to open, it's easy to use, and it's an open architecture. This is really a corporate enhancement... though adding support for Apple's iDisk via WebDAV would be a consumer perk.

In my company we are using WebDav to download or upload files through a https connection between different geographic places. For now, the only solution to use WebDav is to launch Internet Explorer, and use the « Open as Web Folder » option. On some Windows, this options just doesn't work, or is broken. It's very hard to find reliable WebDav clients on Windows as most vendors assume WebDav is natively well supported by Windows. Having a WebDav support in Gecko, independently of Windows WebDav functions, would really help. Moreover this would help us moving out from Internet Explorer (this is the only feature which keeps us from letting down IE).

I wait for this with anticipation. Support for "Digest" authentication in Windows XP is completely broken, so in effect there is no free usable client for WebDAV on Windows at all. If a future Mozilla product would support this in-client, I think everyone would be happy. :-)

I might as well take this bug, since I'm being paid to work on it now... Expect a slew of sub-bugs filed to capture APIs and feature work, as well as interop testing.

It may be wise to investigate what Stellent Content Server does to extend WebDAV. They have a signifigant chunk of the content management business, and use WebDAV with their product. If we know exactly how they extend WebDAV to integrate their features, the appropriate API's could be left for them to work with. Allowing them to bring full WebDAV support to all platforms, rather than just Windows (and limited support for others). I saw their demo once during a training, and it's pretty cool stuff.

I checked a bit of code into /extensions/webdav on the trunk (though I've only actually tested that it builds on the aviary branch, due to a curious fluke in my devel environment), for people who are curious. I'm more happy than unhappy with the interfaces exposed there, though some UTF8/string/nsIWebDAVResource rationalization needs to happen for sure. I would like some e4x equivalent for C++ now, thank you.

(In reply to comment #9) > I checked a bit of code into /extensions/webdav on the trunk (though I've only > actually tested that it builds on the aviary branch, due to a curious fluke in > my devel environment), for people who are curious. I'm more happy than unhappy > with the interfaces exposed there, though some UTF8/string/nsIWebDAVResource > rationalization needs to happen for sure. > > I would like some e4x equivalent for C++ now, thank you. I can't find it. What's the build's url? Thanks

I don't think it's built as part of any nightlies, as well it shouldn't be yet. It's really not ready for user-consumption, and I made mention of it here only to encourage developer review of the interfaces and such.

Mostly I live in extensions/webdav, but I found some stuff in protocol/http that I wanted to fix up (including some warning repairs, etc.).

Comment on attachment 161821 [details] [diff] [review] Some small additions and cleanups for WebDAV support in HTTP Looking for some blessings.

Comment on attachment 161821 [details] [diff] [review] Some small additions and cleanups for WebDAV support in HTTP >Index: src/nsHttpChannel.cpp > char buf[32]; ... >+ PR_snprintf(buf, sizeof(buf), "id=%x&uri=", mPostID); Do you need need to make "buf" longer now that you're tossing in these 8 random chars that you weren't before? >+ cacheKey.SetLength(0); cacheKey.Truncate(); sr=bzbarsky with that.

Comment on attachment 161821 [details] [diff] [review] Some small additions and cleanups for WebDAV support in HTTP >Index: src/nsHttpChannel.cpp > if (!mAllowPipelining || (mLoadFlags & LOAD_INITIAL_DOCUMENT_URI) || > !(mRequestHead.Method() == nsHttp::Get || >+ mRequestHead.Method() == nsHttp::Head || >+ mRequestHead.Method() == nsHttp::Propfind || >+ mRequestHead.Method() == nsHttp::Proppatch)) { hmm... this is ok, but i wonder if we'd want to make this more extensible some how. punt! > nsHttpChannel::GenerateCacheKey(nsACString &cacheKey) ... >+ } else { >+ cacheKey.SetLength(0); } else cacheKey.Truncate(); yeah, i know it looks funny, but that's how things are indented and bracketed in this code. >- PRUint32 promptReason = (proxyAuth ? >- nsIAuthPromptProvider::PROMPT_PROXY : >- nsIAuthPromptProvider::PROMPT_NORMAL); >+ PRUint32 promptReason; >+ if (proxyAuth) >+ promptReason = nsIAuthPromptProvider::PROMPT_PROXY; >+ else >+ promptReason = nsIAuthPromptProvider::PROMPT_NORMAL; heh... i have this in one of my pending patches too ;-) r=darin with indentation nit fixed

Comment on attachment 161821 [details] [diff] [review] Some small additions and cleanups for WebDAV support in HTTP Committed to the trunk, thanks. (buf is safe; %x can't expand to more than 8 chars, which leaves us more than a dozen to spare)

Mass abdication.

what's the webdav support status on April 2010 ?

Target: mozilla1.9alpha1 missed by 'that much' :) This is still a very useful thing for some people.