On Thu, 2 Aug 2018, Daniel Stenberg wrote:
https://github.com/curl/curl/wiki/URL-API
FYI: this has now landed in git. Take it for a spin and let us know how it
works out for you!
--
/ daniel.haxx.se
---
Unsubscribe:
On Tue, Aug 14, 2018 at 11:17:08AM +0200, Daniel Stenberg wrote:
> Aha... well even if this is so, the effects of this will at least be
> mitigated by the fact that libcurl will still canonicalize them even if it
> wouldn't be perfect.
>
> I mean a user who wants to compare two URLs should make
On Mon, 13 Aug 2018, Dan Fandrich via curl-library wrote:
I'm not sure I see the difference between these two approaches. Can you
show them with some example URLs?
For example, + and ! are reserved characters in RFC 3986 but unreserved in
RFC 2326 (RTSP), so a generic canonicalization might
On Mon, Aug 13, 2018 at 09:44:53AM +0200, Daniel Stenberg wrote:
> On Mon, 13 Aug 2018, Dan Fandrich via curl-library wrote:
> >I think there should be a new option for this kind of encoding so the
> >canonical form stays canonical for every URI scheme, but programs that
> >would prefer merely a
On Mon, 13 Aug 2018, Dan Fandrich via curl-library wrote:
I think you're right, it should work. Documenting
(CURLU_URLDECODE|CURLU_URLENCODE) as performing canonicalization is probably
all you'd need, besides ensuring decode and encode happen in the correct
order.
We could perhaps even make
On Sun, Aug 12, 2018 at 06:45:27PM +0200, Daniel Stenberg wrote:
> The current code for the API doesn't offer URL decoding at all when you ask
> for the full URL - since a returned URL is still supposed to be a URL so it
> can't really be "decoded" then. We can of course document that bit to mean
On Sun, 12 Aug 2018, Ray Satiro via curl-library wrote:
I think you overdid it (I know, I'm a little behind on this discussion [1]),
a struct would be simpler.
curl_url_parse(url, );
curl_url_build(parts, );
Is there really a need for a more expansive API?
I don't think exposing such a
On Sun, 12 Aug 2018, Dan Fandrich via curl-library wrote:
I'm curious whether the API can be used to canonicalize a URL, i.e., URL
decode parts that can be decoded without semantic difference but
canonicalize those parts that the specs say must be encoded.
I think it should be possible
The
On 8/1/2018 6:17 PM, Daniel Stenberg wrote:
> In the 2018 user survey, more than 40% of the 395 users who answered
> the question said they'd use a "URL handling" API in libcurl if one
> existed.
>
> I gave it some thoughts the other day and I've now jotted down my
> initial suggestion on how it
On Thu, Aug 09, 2018 at 10:48:32AM +0200, Daniel Stenberg via curl-library
wrote:
> Returning to this, as I've polished the API a bit over the last few days.
> The wiki page has been updated to reflect the changes I've done.
I'm curious whether the API can be used to canonicalize a URL, i.e.,
2018-08-09 14:15 GMT+02:00 Daniel Stenberg via curl-library
:
> ... or should it perhaps just skip the *first* '=' ?
I don't think any URL parsing library cares about = beyond the first
one. Which is why = in name may pose a problem, but in value probably
won't. I'd skip all.
On Thu, 9 Aug 2018, Daniel Stenberg via curl-library wrote:
(replying to myself...9
/* append to query, ask for encoding */
curl_url_set(h, CURLUPART_QUERY, "company=AT", CURLU_APPENDQUERY|
- CURLU_URLENCODE with CURLU_APPENDQUERY set, will skip the '=' letter when
doing the encoding
On Thu, 9 Aug 2018, Daniel Jeliński via curl-library wrote:
char *append = "=44";
Well assuming we want to use the API to build URL based on HTML form with
GET action, curl_url_query_append suggested by Geoff would be much nicer.
Yes, you're right. I've taken a more generic approach that
2018-08-09 10:48 GMT+02:00 Daniel Stenberg via curl-library
:
> Say we want to append this to the query:
>
> char *append = "=44";
Well assuming we want to use the API to build URL based on HTML form
with GET action, curl_url_query_append suggested by Geoff would be
much nicer. In particular, I
On Thu, 2 Aug 2018, Geoff Beier wrote:
The setters would be important to us. I might be bikeshedding here, but the
ability to add to the query would be very nice. So something like
curl_url_query_append(urlp, "numitems", 3)
Returning to this, as I've polished the API a bit over the last few
On Mon, 6 Aug 2018, Daniel Stenberg wrote:
- implement the missing pieces of the API:
I've pushed a first PR of the URL API work to make sure all tests and builds
are happy:
https://github.com/curl/curl/pull/2842
I've listed outstanding work in there.
The API works pretty good already
On Thu, 2 Aug 2018, Daniel Stenberg wrote:
Good or bad? What would your application need and would this work for that?
I've written some initial code for this API [1] now. As I proceed further, I
intend to remove the wiki page as I suspect there will be a lot of details
that have changed
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:
On 01/08/18 23:17, Daniel Stenberg wrote:
Hi,
In the 2018 user survey, more than 40% of the 395 users who answered the
question said they'd use a "URL handling" API in libcurl if one existed.
I gave it some thoughts the other day and I've now jotted down my
initial suggestion on how it
On Thu, 2 Aug 2018, Geoff Beier wrote:
The setters would be important to us. I might be bikeshedding here, but the
ability to add to the query would be very nice. So something like
curl_url_query_append(urlp, "numitems", 3)
That ("numitems", 3) approach is very specific for adding a
We use the uriparser library Radu Hociung mentioned primarily because there
was nothing analogous in curl.
The setters would be important to us. I might be bikeshedding here, but the
ability to add to the query would be very nice. So something like
curl_url_query_append(urlp, "numitems", 3)
An
On Wed, 1 Aug 2018, Radu Hociung wrote:
a "URL handling" API in libcurl
This wheel has already been invented. [1]
[1] https://uriparser.github.io/
Are you suggesting this uses an API that would be worth getting inspiration
from? Personally I don't see a lot I like there...
(Dan already
On Thu, 2 Aug 2018, Dan Fandrich wrote:
My first thought it that it's pretty long-winded. I can't think of many
situations where you might want only one part of a URL, like the port, but
don't want e.g. the host, or the query without the path. What was in the back
of my mind for such an API was
On Wed, Aug 01, 2018 at 11:54:56PM -0500, Radu Hociung wrote:
> On 01/08/2018 5:17 PM, Daniel Stenberg wrote:
> > a "URL handling" API in libcurl
>
> This wheel has already been invented. [1]
The main point of having a libcurl API has to do with reducing security issues
due to differences in URL
On 01/08/2018 5:17 PM, Daniel Stenberg wrote:
> a "URL handling" API in libcurl
This wheel has already been invented. [1]
Cheers.
Radu.
[1] https://uriparser.github.io/
---
Unsubscribe:
yes, I think passing around a struct with this information (and able
to get uri from its parts) would be useful would be more useful then
just direct url construction ... that way one could represent a common
base uri and modify it by just setting new path (in that respect we
may want ability to
On Thu, Aug 02, 2018 at 12:17:26AM +0200, Daniel Stenberg wrote:
> Here's my thoughts:
>
> https://github.com/curl/curl/wiki/URL-API
>
> Good or bad? What would your application need and would this work for that?
> If not, how should we change it to make it better?
My first thought it that
On Wed, Aug 1, 2018 at 3:19 PM Daniel Stenberg wrote:
> Hi,
>
> In the 2018 user survey, more than 40% of the 395 users who answered the
> question said they'd use a "URL handling" API in libcurl if one existed.
>
> I gave it some thoughts the other day and I've now jotted down my initial
>
28 matches
Mail list logo
