Thanks for going into the trouble of raisning this issue with Microsoft. I always hoped somebody will do it some day. Though Microsoft's reaction shows that chances for a bugfix are not too good.

As you already presented the traces, showing space characters within an URI, as well as RFC 4918 you gave them everthing they would need to see the error. The only thing I can do in addition is to point at the relevant parts of the standard documents.

RFC 3986 defines the syntax of URIs. A summary is in Appendix A. Collected ABNF for URI. An excerpt of the part concerning this case looks like this:

  path-absolute = "/" [ segment-nz *( "/" segment ) ]
  segment       = *pchar
  pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
  pct-encoded   = "%" HEXDIG HEXDIG
  unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
  sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
                  / "*" / "+" / "," / ";" / "="

The space character is neither in the "unreserved" set of characters nor in the set of "sub-delims". It is not allowed in the path segment of an URI. But the percent-encoding of the space character, %20, is allowed.

RFC 4918, 8.3.1 Example - Correct URL Handling, makes it - in my opinion - absolutely clear.

Is there any chance to make Microsofts verbatim response, or parts of it, public on this list or somewhere else?

Workaround in davfs2:
While I don't like workarounds for bugs that could easily fixed I am not completely dogmatic about this. There are already some workaraounds in davfs2.
When I looked at this case some time ago I came to the conclusion that I would have to replace part of the Neon library which seems too much trouble. I will have another look at this within the next months. Maybe an easier fix would be to use a patched version of Neon. Would this be an alternative for you? I think I would be able to create the necessary patch.

Cheers
Werner

They use another WebDAV-library. I already explained why davfs2 can not do this kind of work around and I have no intentions to switch to another library, rewriting half of davfs2, just to work around an intentional Microsoft incompatibility.

When sending another proposal how davfs2 should fix this Microsoft bug, please include information about

• your bug reports sent to Microsoft
• Microsoft's response

Yes, it makes me angry when you silently accept Microsoft's intentional violations of standards and then expect free software to solve the problem.

davfs2 does not work with SharePoint because Microsoft does not want you to use free software. How you to react on this is your responsibility.

And if for some reason you really have to use that broken Microsoft server, why don't you avoid the error condition by not using file names with spaces?

Werner

Sharepoint is non-free software. The only one who can fix this bug in Sharepoint is the owner of the software, i.e. Microsoft.
If you need to use this broken software avoid the failure condition; don't use file names with spaces, as Sharepoint can't handle them.

Cheers
Werner

Searching the web I found this:

Some users of Sharepoint had problems because Sharepoint exposed the percent-encoded file names to applications that expect the unescaped form of the file name.

Microsoft supplied a Hotfix (http://support.microsoft.com/?scid=kb%3Ben-us%3B939592&x=9&y=12) for this.

Maybe it was too hot and removed percent-encoding from HTTP-traffic as well, where it is required.

Cheers
Werner

Hello Robert,

I got a similar report about Sharepoint (unfortuneately it was not posted to this forum but to my email adress, so you can't see it).

The problem seems to be a protocol violation by Sharepoint. In response to a PROPATCH request WebDAV servers send an XML-body containing href-elements. These href-elements enclose the URI of the resource. According to the spec space characters in an URI must be percent encoded like '/ein%20test/'. Sharepoint instead sends a space character without encoding. As this is a protocol violation the Neon library will stop processing of this element. (see also http://www.greenbytes.org/tech/webdav/rfc4918.html#url-handling).

A workaround in davfs2 would be a lot of work and additional code as this is handled by the Neon library and I would have to duplicate a lot of library code.

What you can do:
1. Make sure it is this bug. You need option 'debug httpbody' to see the XML-response to PROPFIND. Check wether spaces in href are percent encoded or not. (You may as well catch the HTTP-traffic with Wireshark to exclude any changes by Neon or davfs2.)
2. If spaces are not percent encoded: please contact the server administrator to see if there is any configuration option with Sharepoint to change to the correct behaviour. If there is please report it here for other Sharepoint users.
3. If there is no way to force Sharepoint to compliant behaviour please file a but report to Microsoft. I see no way to work this around in davfs2. It would mean about 1000 lines of additional code.

Cheers
Werner

P.S.: Thanks for the debug log. It shows that at least NTLM-authentication is working now.