Remote-Target detection fails in some cases

[MarcusWichelmann]

Hi,

some clients (for example Linux Mint's file-explorer "Nemo") add the username to the WebDAV-URL like https://[email protected]:8080/....

This causes any Copy & Move-Operation to fail with an exception:

 FubarDev.WebDavServer.AspNetCore.Filters.WebDavExceptionFilter - The destination server didn't return a response FubarDev.WebDavServer.Engines.Remote.RemoteTargetException: The destination server didn't return a response
   at FubarDev.WebDavServer.Engines.Remote.RemoteHttpClientTargetActions.GetAsync(RemoteCollectionTarget collection, String name, CancellationToken cancellationToken)
   at FubarDev.WebDavServer.Handlers.Impl.CopyMoveHandlerBase.RemoteExecuteAsync(IRemoteTargetActions handler, Uri sourceUrl, SelectionResult sourceSelectionResult, Uri targetUrl, DepthHeader depth, Boolean overwrite, CancellationToken cancellationToken)
   at FubarDev.WebDavServer.Handlers.Impl.CopyMoveHandlerBase.ExecuteAsync(String sourcePath, Uri destination, DepthHeader depth, Boolean overwrite, RecursiveProcessingMode mode, Boolean isMove, CancellationToken cancellationToken)
   at FubarDev.WebDavServer.Handlers.Impl.CopyMoveHandlerBase.ExecuteAsync(String sourcePath, Uri destination, DepthHeader depth, Boolean overwrite, RecursiveProcessingMode mode, Boolean isMove, CancellationToken cancellationToken)

Because of FubarDev.WebDavServer.Handlers.Impl.MoveHandler - https://webdav.domain.de:8080/ is not a base of https://[email protected]:8080/Folder/NewFolder.

Code: https://github.com/FubarDevelopment/WebDavServer/blob/2faf70dd0983cd2f776f270e2c81aacecee2a657/src/FubarDev.WebDavServer/Handlers/Impl/CopyMoveHandlerBase.cs#L127

Could you please extend this check to handle corner-cases like that?

I'd also be very helpful if there was a way to disable this check completely when the Remote-Target functionallity is never needed because an URL-Check like this adds some unneccessary development-difficulties when a proxy is used or ports differ.

[fubar-coder]

It's a performance optimization that went wrong here. Maybe we should use a service to implement checks for those stuff.