WebDav MOVE/COPY between servers

Rafa%u0142 wrote:
Hello.
My name is Rafa³ Malinowski. I want (really, I have to) add one feature
to WebDav: support for MVE/CPY with remote servers as 'Destination'.

Why? Do you have any clients that would use it?

As I looked into code and into specification such thing is allowed, but
not implemented yet. I hope I'll have it done with some help from this
list, and I hope it will not take more than one month of work ;)
If someone wants to help me/have some good advice, I would appreciate it.


How do you intend to solve the authentication problem?

BR, Julian

Rafa%u0142 wrote:
Dnia 3-07-2008 o godz. 13:22 Julian Reschke napisa³(a):
>Rafa³ wrote:
Hello.
My name is Rafa³ Malinowski. I want (really, I have to) add one feature
to WebDav: support for MVE/CPY with remote servers as 'Destination'.
>Why? Do you have any clients that would use it?

I will use telnet. After the server work is done I will extend existing
Vinetoolkit Webdav client to support this.

>How do you intend to solve the authentication problem?

SAML2 tokens over GSS with delegations.

K, seems you know what you do :-)

BR, Julian

William A. Rowe, Jr. wrote:
>
>For what it's worth I also did try using the ldap_search_ext_sW call
>directy inside the uldap_cache_checkuserid function but that resulted
>in a filter error.
>
Yup :)
>
So if you were to tweak things to decode utf-8 into unicode and then
invoke
the W flavor, it should work. But I don't think we actually wrap
ldap_search_ext_s in apr-ldap, do we? Meaning that will be a heck of a
messy macro override.
>
>
>

Bill,
the case where we're seeing this none of the arguments contain anything
other than US ASCII characters. If you're ldap_search_ext_sW call
contains only US-ASCII but the returned DN contains UTF-8 shouldn't this
still work or is there something I'm missing here?

Thanks,
Andy

William A. Rowe, Jr. wrote:
>
That's correct. Windows utf-8 code page 65001 or so is only a psuedo
page
in all older and (afaik) newer flavors of windows). So it's returning
this
character in the local code page, can't represent it, and falls back
on '?'.
Yup, and that's what our assumption has been that this is occurring.
>
Using the FnW equivilant, treating the args as utf-8 and passing the
args as
unicode to ldap_search_ext_sW and resolving the return value back to
utf-8
would resolve your issues.
>
>
I'm not certain what you're getting at here. arguments to
ldap_search_ext_sW all already contain valid utf-8 encoding as none of
the arguments contain anything but us-ascii characters. are you
saying there's some extra conversion that needs to be done on us-ascii
only character args?

Thanks,
Andy