cats-uri

[rossabaker]

@isomarcte has taken an interest in rebooting cats-uri. This could potentially replace ours in 1.0. @hamnis and @aeons in particular have done work on ours in the past and may be interested in it.

[FrancescoSerra]

With regards to the current implementation, I think that it's the entity model used to describe a Uri.Path that is fundamentally broken. I'm probably stating the obvious, and probably something that someone else has already written/said, but what looks broken to me is the fact that currently a Uri.Path has Segments that are assumed to be separated by / (and therefore the latter is elided from the internal representation and omitted in the Vector[Segment] of Uri.Path) when, in fact, / is constituent of the Path entity. Hence, the solution IMO should be in redesigning Path so that / becomes some subtype of Segment and its presence (or absence) can be accounted for in the segments member of Path, dropping the artificial endsWithSlash flag.

[armanbilge]

@isomarcte I know it's still early days for cats-uri, but did you have any thoughts on what Path and Segment might look like that we could backport into 0.23? Thanks!

[isomarcte]

Backporting will be hard. There are a number of issues with the current implementation, and as talked about extensively on https://github.com/typelevel/case-insensitive, some of them are also related to our handling of Unicode.

However the current plan is for http4s to ingest case-insensitive on 1.x.x and not 0.23.x that presents a problem.

We could possibly release a backport of cats-uri building off of case-insensitive 1.x.x and then push it into http4s with the knowledge that the such a version of cats-uri will be incorrect for certain exotic Unicode edge cases, but I'd really rather not release of version of cats-uri which I know deviates from the RFCs....

It's quite a tricky issue.

I think the best course of action is for us to wait for case-insensitive 2.x.x, cats-uri, and then get to 1.x.x on http4s. @armanbilge @rossabaker I've been a bit out of the loop recently since I've been changing jobs, do we have an approximate target date for http4s 1.x.x we'd like to hit? Or a set of features we want to land first?

[armanbilge]

@isomarcte no problem, great to have you back! 😁

I think the best course of action is for us to wait for case-insensitive 2.x.x, cats-uri, and then get to 1.x.x on http4s.

💯 agree with that plan and I'd like to support you as much as I can with that so please let me know how ... with the caveat that I have limited headspace for RFCs and stuff, sorry 😅

do we have an approximate target date for http4s 1.x.x we'd like to hit? Or a set of features we want to land first?

No date really AFAIK. There's still plenty of work to be done in the milestone. There's the MTL middlewares, putting a Resource into HttpApp I think, still some work on entities, taking advantage of literal types now that we dropped 2.12, etc. etc. etc.
https://github.com/http4s/http4s/milestone/56

Thanks!

[bblfish]

Having tried lemonlabs Uri in banana-rdf and using http4s URi I have some ideas of key elements to improve http4s Uri.

1. Http4s Uris are currently actually URLs, and should be named as such. Urls can have paths, be relativised, absolutized and be used for requests using something like an http framework. URNs cannot. We have type URI = URL | URN
2. Http4s should take onboard the typing lemonlabs uses, that clearly distinguishes absolute Urls, relative Urls (and there relative path absolute: urls starting with /) and also schema relative urls. That would allow Http4s to let us know if a Request is meant to take an absolute or a relative Url for example. There may be clients that can take both, but not all clients can. A client that has no connection cannot take a relative Url. A client bound to a connection can take a (path absolute) relative Url).

Further crazy requirements:

1. Ideally (here we may be going beyond what is possible) it would be possible for the interface to be implemented so as to allow unique storage of URIs to re-use components. So one would be able to have a garbage collected store of URIs starting with "https" then followed by domain components, etc... so that Uris could be compare using eq for equality and use as little memory as possible.
2. In RDF one has so many URIs the frameworks are careful to minimally parse them, leaving perhaps invalid uris in graphs rather than having to parse the structure of them. I wonder if there is a clever way of optionally integrating that requirement.
3. Perhaps one also wants to map URIs to 64bit Long numbers. At the RDF layer one does not need to look into the URIs at all: one could just as well use 64bit long comparison to test for equality, once those are parsed and stored in a DB.

Having an excellent real URI class that encompasses both URNs and URLs would be very helpful when writing application code. On the web application code proceeds as follows:

1. client fetches hyper-text or hyper-data resource on the web (using http4s)
2. it parses the content, often containing URIs (relative and absolute URLs and sometimes even URNs) and may follow any number of those URLs in sequence or in parallel (going back to 1.).

If the code could use the same URI structure in the parsing stage as it uses in the fetching stage that would make for much nicer and smoother coding. Note in RDF URIs are the core of the naming scheme, so one is using them all the time for every data structure. In banana-rdf I added support for relative urls, as those are useful when fetching data and also when posting graphs to a container: the server decides on the URL of the created resource and so the graph sent has to be one that can contain relative Urls.

Note there are other places where Urls turn up in HTTP4s

1. in Link relation headers. Those can contain relative URLs, so to be able to work with those one needs to know what the previous request to which the Response was an answer to is. If that Request contains a relative URLs then one can only get a relative URLs answer by resolving the first with the second. That can be useful to make a request, but only if the client is tied to a connection.
2. When using Entity Decoders it can help when parsing RDF to know what the absolute URL of the request was. Without that one cannot get a real RDF graph, but only a relative Graph (a concept I added typed support for in banana-rdf recently). Relative Graphs don't allow merging of information, due to possible name-clashes, so they are very different types of things. (note: one could merge relative graphs with absolute path urls if they all came from the same domain...). Anyway it feels like it would help if EntityDecoders could pass the Url of the original request.

(see issue typelevel/cats-uri#6)

PS. Relative URLs are simply versions of what is known in linguistics and philosophy of language as indexicals. They take part of their meaning from a context. That is when I use "you" speaking to someone in one context that can very well refer to someone else than when I use "you" in another context. Or if I give directions to a place starting from a position on a map, such as "go to the end of the road, turn right and walk 100m", that is going to lead someone following the process to different places if the starting point is changed. Logic prefers absolute URLs, as it allows one to avoid name clashes, but pragmatics requires relative ones, and HTTP is in the area of pragmatics. (I wrote quite a lot about this, pragmatics and the web in my second year Phd report.)

[bblfish]

The above makes me think that there should be a notion of a variable that could be used usefully in working with relative urls. As we saw if we have relative urls </foo/bar/cat.jpg>, </foo/baz/dog.jpg>, ... are found in a document from a connection to some server of which we don't know the domain, we would like to indicate that they can both be used on the same connection, but not another relative Url </foo/bar/cat.jpg> that was taken from a completely different connection. Ie we would like to resolve them to full urls with a variable
<${connection1}/foo/baz/cat.jpg> and <${connection2}/foo/baz/cat.jpg>. $connection1 and connection2 may be unknown, for example to a server using a p2p extension to HTTP as detailed in w3c/architecture#14 . For a server the client does not have a domain, and if it were to send a request with content referring to data on its side, that would be a relative url only valid on that connection. The server may want to describe that connection and keep a history of the exchange and the resources on the client without risking merging it with resources from other such connections.