Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Webdav regression between 4.0.2 and 4.1.x / 4.2.x #6577

Closed
cyberduck opened this issue Mar 8, 2012 · 6 comments
Closed

Webdav regression between 4.0.2 and 4.1.x / 4.2.x #6577

cyberduck opened this issue Mar 8, 2012 · 6 comments
Assignees
@dkocher
Labels
bug high priority thirdparty Issue caused by third party webdav WebDAV Protocol Implementation

Comments

@cyberduck
Copy link
Collaborator

25b982f created the issue

Hello,

Since I upgraded Cyberduck from 4.0.2 I saw a regression browsing a SharePoint webdav share.

I tested all of the subsequent versions of Cyberduck (except 4.1.1 that I could not find to download), and also tested nightly 9393, with no success.

Symptoms :
When browsing the share, there is a directory that is missing (I'm out of luck, as it's the most important for me...)
This directory has a space in its name (and also in its display name), which may be the reason why it's the only one not appearing.

Attached are two files with the content of the Log panel and the full content of the transaction (some sensitive info were removed)

Best luck for debugging.

Regards,

Ludovic
@cyberduck
Copy link
Collaborator Author

25b982f commented

Ok, bad news, I cannot attach files it seems, and reCaptcha seems not configured... :

Submission rejected as potential spam (Maximum number of external links per post exceeded)
Trac thinks your submission might be Spam. To prove otherwise please provide a response to the following.
Input error: k: Format of site key was invalid

@cyberduck
Copy link
Collaborator Author

@dkocher commented

This is a regression of #2223.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

The issue is that the server does not properly URI encode references in the XML response. With the new WebDAV implementation in Cyberduck, we are no more strict and ignore invalid responses.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

We previously decided not to provide a workaround for this issue. See #6094.

@cyberduck
Copy link
Collaborator Author

25b982f commented

Sorry, duplicate post, I posted in #6094 also...

The response is :

<D:response><D:href>https://XXXXXXXXXXXXX.sharepoint.emea.microsoftonline.com/XXXXX/Documents comptables</D:href><D:propstat><D:prop><D:displayname>Documents comptables</D:displayname><D:lockdiscovery/><D:supportedlock/><D:isFolder>t</D:isFolder><D:iscollection>1</D:iscollection><D:ishidden>0</D:ishidden><D:getcontenttype>application/octet-stream</D:getcontenttype><D:getcontentlength>0</D:getcontentlength><D:resourcetype><D:collection/></D:resourcetype><Repl:authoritative-directory>t</Repl:authoritative-directory><D:getlastmodified>2012-03-07T20:57:03Z</D:getlastmodified><D:creationdate>2012-03-05T14:48:59Z</D:creationdate><Repl:repl-uid>rid:{93D90163-CECA-41E6-A705-EF69781A4EB9}</Repl:repl-uid><Repl:resourcetag>rt:93D90163-CECA-41E6-A705-EF69781A4EB9@00000000000</Repl:resourcetag><D:getetag>&quot;{93D90163-CECA-41E6-A705-EF69781A4EB9},0&quot;</D:getetag></D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>

I understand that you suggest spaces to be encoded as %20, as in http://www.ietf.org/rfc/rfc1738.txt , right ?

Would you accept a patch with a (possibly hidden) configuration option to implement a workaround for this very specific issue ?
I'm not happy with the situation and the fact that some vendors do not respect the standards, but let's face it, it's far easier (and quicker) for me to patch this than 1) to have the vendor provide a fix for this issue on its product and all impact products (browsers, operating systems, third-party components) and 2) have this propagated to the shared folder than I want to access.

Regards,

Ludovic.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [comment:5 llange]:

Sorry, duplicate post, I posted in #6094 also...

The response is :

<D:response><D:href>https://XXXXXXXXXXXXX.sharepoint.emea.microsoftonline.com/XXXXX/Documents comptables</D:href><D:propstat><D:prop><D:displayname>Documents comptables</D:displayname><D:lockdiscovery/><D:supportedlock/><D:isFolder>t</D:isFolder><D:iscollection>1</D:iscollection><D:ishidden>0</D:ishidden><D:getcontenttype>application/octet-stream</D:getcontenttype><D:getcontentlength>0</D:getcontentlength><D:resourcetype><D:collection/></D:resourcetype><Repl:authoritative-directory>t</Repl:authoritative-directory><D:getlastmodified>2012-03-07T20:57:03Z</D:getlastmodified><D:creationdate>2012-03-05T14:48:59Z</D:creationdate><Repl:repl-uid>rid:{93D90163-CECA-41E6-A705-EF69781A4EB9}</Repl:repl-uid><Repl:resourcetag>rt:93D90163-CECA-41E6-A705-EF69781A4EB9@00000000000</Repl:resourcetag><D:getetag>&quot;{93D90163-CECA-41E6-A705-EF69781A4EB9},0&quot;</D:getetag></D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>

I understand that you suggest spaces to be encoded as %20, as in http://www.ietf.org/rfc/rfc1738.txt , right ?

Would you accept a patch with a (possibly hidden) configuration option to implement a workaround for this very specific issue ?
I'm not happy with the situation and the fact that some vendors do not respect the standards, but let's face it, it's far easier (and quicker) for me to patch this than 1) to have the vendor provide a fix for this issue on its product and all impact products (browsers, operating systems, third-party components) and 2) have this propagated to the shared folder than I want to access.

Regards,

Ludovic.

You could provide a patch for sardine which we make use of.

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@dkocher dkocher

Labels
bug high priority thirdparty Issue caused by third party webdav WebDAV Protocol Implementation
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@dkocher @cyberduck