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

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

Comments

@cyberduck
Copy link
Collaborator

@cyberduck cyberduck commented Mar 8, 2012

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

@cyberduck cyberduck commented Mar 8, 2012

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

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Mar 8, 2012

@dkocher commented

This is a regression of #2223.

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Mar 8, 2012

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

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Mar 8, 2012

@dkocher commented

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

Loading

@cyberduck cyberduck closed this Mar 8, 2012
@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Mar 8, 2012

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.

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Mar 8, 2012

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

Loading

@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.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants