path segment functions

[dsheets]

There should be interface functions to operate over path segments and provide the same kind of services that are available to query components.

[Drup]

That would be useful in ocsigen as well, some kind of segmented_path: string list function.

[dsheets]

A prime test for this functionality will be the original segment-of-only-%2F of 37771d7c7a223b6302c961e7d96219ef729d1ced. Other segments containing %2F work fine.

[rgrinberg]

I'm +1 on this. to give an example of the kind of this kind functionality being useful in the real world [1]:

val add_path_to_url :  string list -> string -> string

Would be great to have something like this.

[1] https://github.com/rgrinberg/gapi-ocaml/blob/master/src/gapi/gapiUtils.mli#L19

[dsheets]

You can achieve most of that with resolve:

# Uri.(resolve "" (of_string "/foo/bar/") (of_string "baz/quux/"));;
- : Uri.t = /foo/bar/baz/quux
# Uri.(resolve "" (of_string "/foo/bar/") (of_string "/baz/quux"));;
- : Uri.t = /baz/quux
# Uri.(resolve "" (of_string "/foo/bar/") (of_string "../baz/quux"));;
- : Uri.t = /foo/baz/quux
# Uri.(resolve "" (of_string "/foo/bar") (of_string "baz/quux"));;
- : Uri.t = /foo/baz/quux

[rgrinberg]

It's a decent workaround for sure. But it's hard to imagine a user discovering it on their own and I thought this ticket was about adding helpers for this.

[dsheets]

I do think more needs to be done to make users aware of the power of resolve.

This issue is about exposing the structure of the path component directly as it must be represented internally. Right now, paths clearly have structure but are opaque at the API level. The library should be able to help users more when they want to route HTTP requests or walk directory trees.

[mseri]

+1 for this, would be really useful