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

Reply via email to