On 4/28/2019 9:47 PM, Christopher Head via curl-library wrote:
> On Sun, 28 Apr 2019 16:57:39 -0400
> Ray Satiro via curl-library <curl-library_at_cool.haxx.se> wrote:
>
>> That's not allowed. To PUT is to completely replace a resource.
> Then it seems that upload resuming, which libcurl does support, ought
> to be banned, too, oughtn’t it? After all, using Content-Range to
> resume an interrupted upload is modifying the existing resource by
> appending more bytes on the end, not replacing a resource wholesale.
> Yet upload resuming using Content-Range seems not to be all that
> uncommon (at least, searching this list’s archives showed a few results
> of people doing this in the past, and CURLOPT_RESUME_FROM does apply to
> PUTs’ request bodies).
>
> In my defense, I’m not the one who decided to use PUT this way. Amazon
> did [1], and I’m just following their rules.
>
> If this is sufficiently weird, I certainly don’t mind using
> CURLOPT_HTTPHEADER. I just wanted to check if I was missing something
> that would allow this to be done in a nicer way.
>
> [1]
> https://docs.aws.amazon.com/amazonglacier/latest/dev/api-upload-part.html

CURLOPT_RANGE specifically as far as I know is only supposed to be used
for download, not upload (can anyone confirm?), which would explain what
you observed [1]. Anyway, I think what Amazon is doing is unusual and
you'd have to use CURLOPT_READFUNCTION and CURLOPT_SEEKFUNCTION (adding
in your offset) and set Content-Range and amazon specific headers yourself.

[1]: https://curl.haxx.se/mail/lib-2019-04/0075.html

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2019-04-30