Android Question Webdav access via OkHttp

[laserted]

Greets! It's another WebDav question! While the search results from the forum have been somewhat helpful, part of my misunderstanding is that my particular request doesn't follow the same format as those prior. In particular, I don't *think* I need to map or create a multipart json request. The application is webdav to a nextcloud/owncloud/generic webdav server - and I realize that I am not the first one to ask this type of question, however there don't seem to be any "here's a solution" responses to those. The posts simply died off. :-(

I have a functioning server and can access it via curl, such as:

a) create subfolder2 inside of user1's workspace, wherein username:password are credentials and --ssl-no-revoke fixes a curl issue:

curl -u username:password -X MKCOL https://server.tld/remote.php/dav/files/user1/subfolder2 --ssl-no-revoke

In raw, it transforms to this:
MKCOL /remote.php/dav/files/user1/subfolder2 HTTP/1.1
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
Host: server.tld

(such that the auth is straight base64 encoded of the "username:password" credential, including the separator)

b) transfer a local file myphoto.png to that prior-created folder on the server:
curl -u username:password -T myphoto.png https://server.tld/remote.php/dav/files/user1/subfolder2/myphoto.png --ssl-no-revoke

In raw that looks like:
GET /remote.php/dav/files/user1/subfolder2/myphoto.png HTTP/1.1
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
Host: server.tld

I have no idea why the -T (transfer) turns into a GET request when viewed in raw, perhaps that's just an anomaly from reqbin.com. Also, the --ssl-no-revoke flag, which is absolutely necessary, gets dropped off the raw. So raw probably isn't helping me any.

Where I am really lost is how does the above turn into an httpjob? How does -T or MKCOL become a type of request, or a header?

I've used httputils in quite simple processes (very straightforward GETs and POSTs) for a long time, but converting this to hand-written http requests has taxed my google-fu severely.

I'm hoping some of those that were doing prior work with webdav attempts might share some of their earlier successes or understanding?

Thanks,
Ted.

 

[drgottjr]

the -T option should have resulted in uploading the file.
GET is curl's default operation, so something freaked
it out, and it reverted to the default.
you might try again with a -v option to see what the
server is trying to tell you.

technically, okhttputils can work, at least to upload a
file. you would use PUT as the command. see what you
get with that. actually, try it with curl first. it that works,
okhttp should (with appropriate headers).

okhttputils is not set up for webdav; it's
a b4x wrapper to facilitate our typical http(s) needs.
an okhttp client (in java) does support webdav. nothing
stopping you from talking to one (or one of the many
webdav-supporting libraries out there) with a java object.

 

[laserted]

Thank you for that insight. Perhaps the most important takeaway there is that it is becoming a deeper rabbit-hole that I do not care to go down at this time. My PHP chops are much stronger and I do have access to the server platform, so writing a custom api for this purpose that uses a more traditional post request from b4a and using okhttp within its constraints may be the more viable option. Certainly quicker for me to write and troubleshoot.
If another answer pops up that says "hey, here's a cool template solution for direct access", I'll be happy to try it out, but I'm not out of horsepower on the server, so receiving and redirecting the request content isn't any significant impact.

I don't particularly care for finding forum posts that don't actually have answers, so for the sake of posterity, to any future readers: my path will be to write a php script and place it on the server that redirects the request to a local curl request to the webdav server itself. This may seem a little excessive and untidy, however the wrong direction in this case would be to simply store the file on the local filesystem. Since I'm working with nextcloud/owncloud instances, that platform is actually intercepting the webdav (to a certain degree - overseeing might be a better statement) and capturing metadata for its own database that it presents for other clients. (I'm pretty sure NC and OC use Sabre as the actual webdav server, but direct file access is somewhat discouraged). To that end, writing a php script that acts as a simple post receiver, takes the file as content, the file path and the user credentials as parameters, then internally performs 2 curl requests - one to make sure the relevant file folder structure exists and create if not, the second to handle the file itself, then return a simple ok/fail response -- turns out to be a fairly straightforward and stable solution. If your forum searching doesn't point you in the right direction, similar httputils/php connections have been discussed here: https://www.b4x.com/android/forum/t...-httpclient-initializepost2.13225/#post-74487

Many thanks,
Ted.