On 03/08/18 11:32, Daniel Stenberg wrote:
> On Fri, 3 Aug 2018, Samuel Hurst wrote:
>> For example, being able to build new URLs from relative ones. I can't
>> quite tell from the examples provided whether curl_url would do
>> relative transformation if the urlhandle is already valid. I can see a
>> use case where I'd want to do the following:
>>
>> CURLURL *url_handle = NULL;
>> curl_url("https://example.org/hello", url_handle, 0);
>> ...
>> curl_url("/image.png", url_handle, 0);
>
> Ah, yes. I like this suggestion - even if "/image.png" could've been
> handled with just setting a new path. I suppose "../image.png" or
> something would be a better example.
>
> As for the specific API to deal with a relative URL, I think I prefer to
> have it not overload curl_url() for that. As I prefer the "alternative
> B" API, I think we can just add a dedicated CURLUPart for a relative
> URL. Then it would be used like this:
>
>   curl_url("https://example.org/path/to/hello", &url_handle, 0);
>
>   curl_url_set(url_handle, CURLUPART_RELURL, "../image.png", 0);

It was a deliberately very simple example. In terms of what's workable
in practice, I'll leave that up to you to decide. I can just forsee
plenty of reasons why you might want to easily parse relative URLs to an
object you've already requested, say from link tags in a HTML page, or
media segments referenced from some base URL in a media manifest.

These may actually be fully qualified URLs, so as long as
CURLUPART_RELURL doesn't explode when that happens, I don't see any
problems with your solution. Not having to parse that at the application
level would certainly make code cleaner (at least at the application
side...) and reduce a lot of duplication.

Not limiting it to CURLUPART_PATH overcomes issues when people use
protocol-relative URLs, which I'd imagine that CURLUPART_RELURL would be
able to process.

>> Some form of handle copy might be useful here too, if you're having to
>> do a lot of relative transformations from a single base URL.
>
> Yes, something like this:
>
>   CURLURL *handle = curl_url_dup(inhandle);

Perfect.

>> In addition, our own URL classes support returning the path as an
>> array of strings corresponding to to each individual path segment.
>> We've certainly found use for this in the past, and others may also
>> find this useful.
>
> Mm, maybe. Is there anything else to that than splitting the path on
> every forward slash?

Our implementation doesn't do any more than that at present.

-Sam
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-08-03