Dear Ray, Signing for both GET and/or HEAD request isn't the problem, that can be done. Except when you're not in control of the signing process (which is out of scope).
It is more that I don't want to pass two urls to qemu-img, one for the HEAD request and one for the GET request. I also tried the Range request, but it will as a minimum return 1 byte, which still is a response body and hence will trigger the CURLE_WRITE_ERROR. With the response I got from Daniel I was able to figure out my problem [1]. As you pointed out using -X is something to stay away from. For me, it's actually the outcome. [2] [1] http://curl.haxx.se/mail/lib-2015-12/0041.html [2] http://lists.nongnu.org/archive/html/qemu-devel/2015-12/msg01419.html -- Met vriendelijke groet / Kind regards, Boris Schrijver PCextreme B.V. http://www.pcextreme.nl/contact Tel direct: +31 (0) 118 700 215 > On December 9, 2015 at 11:48 PM Ray Satiro via curl-library > <[email protected]> wrote: > > > On 12/9/2015 12:01 PM, Boris Schrijver wrote: > > I was trying out a few things in qemu-img, a virtualisation utility which > > depends on libcurl. And with the signed-urls recently becoming more common, > > I > > stumbled upon the following issue. The signed-urls I will be talking about > > are > > for S3 [1]. > > > > A signed-url can have it's HTTP method be included in the signature, so a > > signed-url with the GET method included in it's signature, when used by a > > HTTP > > HEAD method will return a 403 forbidden. > > > > Program's like qemu-img will want to first get the Content-Length. Normally > > this > > would mean a HEAD request. But that's not possible, hence the signed-url. > > I don't understand why you're signing for the GET method when the HEAD > method is what you're supposed to be using and therefore is what is > supposed to be signed, isn't it? You sign the method the client is using > (if you accept it), at least that's my interpretation of [1]. Do you > have code that shows how you're doing this? > > Or do you have a third party somewhere that signs the request for you, > and that's why you can only use GET? In other words, you are saying that > a third party giving you access to one of their Amazon resources gives > you an authentication request signed for GET even when you use HEAD? (I > tried this just now with GitHub => AmazonAWS and they do that, hence my > hunch). > > > What I basically want is: curl -X GET -I http://random.url/object > > If you can't use HEAD for no body I guess you could try limiting the > body to 1 via Range like curl -r 0-0. If it works you'll get 206 and a > reply header like Content-Range: bytes 0-0/1048576 so you can get the > size from that. I'd stay away from -X if you can [2]. > > > I tried to implement it in qemu-img [2] but ended up always getting a > > CURLE_WRITE_ERROR, due to the body not being written anywhere. > > > > Is it possible to include a curl_easy_setopt() option to discard the > > response > > body and stop the connection after the HEADER? So that the > > curl_easy_perform() > > will still return 0 on success, and we don't need to check for a > > CURLE_WRITE_ERROR? > > > > [1] > > http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html#ConstructingTheAuthenticationHeader > > [2] https://lists.nongnu.org/archive/html/qemu-devel/2015-12/msg01131.html > > I'd guess that should be handled in qemu, it's not expecting a body so > if it's going to receive something as the body they'll have to deal with > that. In other words if you are looking to make a modification I think > you should focus on qemu not libcurl. > > > [1]: https://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html > [2]: http://daniel.haxx.se/blog/2015/09/11/unnecessary-use-of-curl-x/ > > ------------------------------------------------------------------- > List admin: http://cool.haxx.se/list/listinfo/curl-library > Etiquette: http://curl.haxx.se/mail/etiquette.html ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
