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