212342 - (webdav) WebDAV support in browser (network abstraction layer?)

Status: RESOLVED WONTFIX

(Core :: Networking, enhancement)

Description

[Aaron Kaluszka]

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.

Comment 1

[Aaron Kaluszka]

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

Comment 2

[Marcos Pinto]

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 ;-)

Comment 3

[Paul Everitt]

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.

Comment 4

[Robert Accettura [:raccettura]]

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.

Comment 5

[Hadrien Nilsson]

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).

Comment 6

[Trejkaz]

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. :-)

Comment 7

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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.

Comment 8

[Robert Accettura [:raccettura]]

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.

Comment 9

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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.

Comment 10

[Mauro Braggio]

(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

Comment 11

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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.

Comment 12

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Attachment: Some small additions and cleanups for WebDAV support in HTTP

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 13

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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

Looking for some blessings.

Comment 14

[Boris Zbarsky [:bzbarsky]]

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 15

[Darin Fisher]

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 16

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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)

Comment 17

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Mass abdication.

Comment 18

[will_eraser]

what's the webdav support status on April 2010 ?

Comment 19

[Kym Farnik]

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