curl / Mailing Lists / curl-library / Single Mail

curl-library

Re: Ranged PUTs, Content-Range, and Content-Length

From: Christopher Head via curl-library <curl-library_at_cool.haxx.se>
Date: Fri, 3 May 2019 20:23:30 -0700

On Fri, 3 May 2019 17:38:37 -0400
Ray Satiro via curl-library <curl-library_at_cool.haxx.se> wrote:

> I think this will be unclear to the reporter since he basically wants
> to upload arbitrary parts of a file [1]. curl supports resuming an
> upload and sets Content-Range in that case (CURLOPT_RESUME_FROM and
> CURLOPT_INFILESIZE) but does not support CURLOPT_RANGE for arbitrary
> parts, would you agree?

I think the situation is pretty clear to me: I’m doing something
outside what Curl supports, so I should just use CURLOPT_HTTPHEADER to
set Content-Range. I’m fine with this.

I think I’m now just more confused about why Curl even supports
CURLOPT_RANGE for PUTs at all. I’m honestly not seeing how it’s
possible to use it for *any* purpose, not even for resuming an upload
with intent to complete the whole file: if you set INFILESIZE to the
size of the file then Content-Length is too big, and if you set
INFILESIZE to the size of the residue then the number after the slash
in Content-Range is too small. So RESUME_FROM for PUTs seems to be OK
in the sense that it’s not really standards compliant but does
something vaguely sensible which is useful with some servers, but
CURLOPT_RANGE for PUTs seems to never do anything useful, and yet,
despite that, some effort was put into implementing it.

So, for my own purposes I have no problem: I’ll just use HTTPHEADER,
given that it seems my desired behaviour wasn’t ever meant to work. But
I’m left wondering about the rest.

-- 
Christopher Head

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html

Received on 2019-05-04