tavinus
Add -A (user-agent) and -e (referer) options for curl
This is especially useful to identify specific uploaders when using cloudsend.sh script.
@deajan Looks good. I need to test it. Can you provide examples to make it easier for me to test and write the documentation?
Well:
Add custom user agent to request
# cloudsend.sh -A "mycustomuseragent" /path/to/file https://my.nextcloud.instance.local
Add a http referrer to request
# cloudsend.sh --referer "somestring" /path/to/file https://my.nextcloud.instance.local
I don't really know what kind of examples you would need here. I will explain it's practical usage though.
Some services are behind proxies, that detect user-agent strings, and redirect depending on user agent. Also, some people (like me) use the referer string to pass client information, such as which script / api has actually made the request. This helps me make statistics of API call origins.
Hi there. I finally spent a full day trying this. It kind of works, but complex user-agents would not be parsed correctly no matter what I did.
I spent countless hours trying to get the " -A "$USERAGENT"" parameter to be transferred correctly, but it would always break if it had spaces. I tried double-quoting, printf "%q" and pretty much anything I could think or find. Full day lost on this.
Then I just gave up and rebuilt the curl calls to check if we have a user-agent and then call it with -A "$USERAGENT", quoting it directly in the call. If there is no user agent, the other call option just don't use the $USERAGENT variable at all. It was certainly a lot easier and faster to code, but I really wanted to understand why I can't escape or quote the user-agent part. And wanted to avoid having to maintain 2 different calls. Anyways, this time my stubbornness didn't pay off.
One thing that DID work was to urlencode the user-agent string. The only problem is that I could not find any info if that is a valid option. I mean, if the servers are ok on receiving the user-agent url encoded (spaces as %20 for example). In my tests, I could send "GARBAGE" as the user-agent and it would work without problems. So, not sure if the url-encoded string is valid. If it is valid, we could just swap spaces for "%20" and it would work fine. Cloudsend already has a function for that internally, it works for other things.
I will merge your PR and then push my modifications now.
Sorry for the delay, but as expected this needed revision, testing and debugging.
Maybe there's something quite stupid that could resolve all the issues. Why not pass "$@" directly to curl once you have popped the parameters specific to cloudsend ? This way, any parameter for curl could just work. Didn't think about this when I made the PR.
I edited the comment above a bit.
I did try to pass "$@", but that usually made things even worse. It would suffer from the same problem of not escaping spaces properly and then break even more things, like the header (which also has spaces).
I tried so many things that I am too tired to mention all of them.
${var@Q} and "$(printf ' \-A %q' ${var})" should work. But they do not for some reason. Sending the quotes should also work.
The main problem is passing both -A and $USERAGENT in the same variable. This means you can't quote the whole thing in the curl call, because that makes it become a single token. -A VAR instead of -A / VAR.
I even tried passing them separately, but then the curl call would complain about having an empty parameter (because when you quote empty in the curl call, it actually goes as an empty parameter).
Anyways, let's push the less pretty version that always works.
I really wonder if it is valid to just encode spaces as %20 for the user-agent though.
That would also be a valid solution.
Looks good to me, my work (which required user agent / referrer) works with this release. Thanks ;)