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

SEARCH HTTP method is not supported #427

Open
ghost opened this issue Dec 29, 2021 · 7 comments
Open

SEARCH HTTP method is not supported #427

ghost opened this issue Dec 29, 2021 · 7 comments

Comments

@ghost
Copy link

ghost commented Dec 29, 2021

Issue

When trying to make a request using SEARCH method like desribed here, exception is thrown
https://docs.nextcloud.com/server/latest/developer_manual/client_apis/WebDAV/search.html

Example code:

val request = NextcloudRequest.Builder()  
        .setRequestBody(body)  
        .setMethod("SEARCH")  
        .setUrl(Uri.encode("/remote.php/dav/", "/"))  
        .build()
val response = nextcloudApi?.performNetworkRequestV2(request)

Exception:

com.nextcloud.android.sso.exceptions.NextcloudUnsupportedMethodException: The requested HTTP Method is not supported yet! Please contact the developers of the Android Single-On Library for Android
@stefan-niedermann
Copy link
Member

My two cents: I still see no reason why we should limit the HTTP verbs to a tiny subset. We had requests for PATCH and HEAD in the past, others will probably follow. Each time we have costs to add a requested verb to both, the SSO lib and the Files app. Can't we just allow each method? (Of course it is up to the user to ensure that there is no nonsense in the header).

@tobiasKaminsky
Copy link
Member

Reason is simply time, as we have to add this manually:
https://github.com/nextcloud/android/blob/55bdbc1f55d2586befb1c8455b172f26e0c7abf2/src/main/java/com/nextcloud/android/sso/InputStreamBinder.java#L247

And back then I wanted to avoid to add untested methods…

@stefan-niedermann
Copy link
Member

avoid to add untested methods…

This argument is like having a whitelist for URLs - in my opinion it is up to the responsibility of the 3rd party app developer to ensure that the method is valid and accepted by the endpoint.

In the worst case, the server will respond with 405 Method Not Allowed or even a 500. But that is nothing that breaks the Files app or the SSO lib, it just hits the user as if there was a typo in the URL and a 404 comes back.

Am i missing something here? 😕

@tobiasKaminsky
Copy link
Member

True…Then my time argument still counts 🙈🙈🙈

@stefan-niedermann
Copy link
Member

That's what i am trying to say: If we would drop the whitelist and just allow developers to use each method they want, we could safe time to adjust the whitelist in the SSO list, in the Files app and handling the issues / requests 🙂

If a developer wants to use FOOBAR, well so what? they will get an error and then use POST or whatever is correct^^

@tobiasKaminsky
Copy link
Member

I fear that is not possible, as they keyword "SEARCH" needs to be tranferred to our NCSearchMethod (just an example).
This cannot be done automatically.

There are specific classes for every webdav type within our used http library. Of course 3rd party libraries could integrate those and then pass the entire class, but this then circumvents somehow the idea of this lib.

@stefan-niedermann
Copy link
Member

@pedja1 are you still interested in this feature? Looks like nothing is actually blocking here, so maybe you want to contribute this HTTP verb? Tobias already mentioned the side of the Nextcloud Files app, and I am sure we can help you to point out the relevant positions in the SSO lib.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants