Hi All,

A slightly awkward question here, so here's some background as to why
I'm asking it. I've got a bit of software that uses libcurl, and I'm
doing multiple small range requests of a larger resource. We've recently
been doing work with various caching reverse proxies, and we've
discovered that some proxies (cough Varnish cough) don't handle multiple
range requests at all and if you request more than one range it just
returns the whole resource.

As this is incredibly inefficient for what we're trying to do, I'm now
spotting when one such multiple range request doesn't work, and then
marking it as bad and then doing each range individually.

What I'm currently doing is watching for a not-206 response and flagging
it as a "bad" origin. However, as the resource in question is accessed
over TLS and I'm behind a forward proxy, I'm getting the 200 OK back
from the proxy CONNECT.

I see that in the past[1] there's been an attempt to add in a mechanism
to not give back the proxy responses, but as far as I can tell this
never made it into curl proper.

I'm changing my code so I'm waiting for the last 2xx series response to
figure out what to do with it, but as I now won't know this until after
I've received data it lessens my ability to cancel the transfer and save
myself bandwidth I don't need. Due to the way the code is already
structured means I'm holding a lot of state and it looks messy. Or I
could wait until the end of a transfer, use CURLINFO_RESPONSE_CODE but
then I've received many MB of data when I only wanted a few kB.

Is there any better way to do this under libcurl? Maybe a method of
finding what context a header is being delivered to the application in?

Best Regards,
-Sam

[1] -
https://github.com/curl/curl/commit/2612238088079215c258b5cd58f166956dd4fa66
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-10-03