ObjFW  View Ticket

Currently, OFURL only supports, as the name implies, URLs. However, it would be nice to also be able to handle URIs. As it would be bad to have two classes, the best way forward would be to rename OFURL to OFURI and add URI support as per 3986 to it.

It seems the main changes needed would be:

• Rename to OFURI and change OFURL -> OFURI everywhere
• Drop fragment entirely
• Add support for parsing URIs with no authority, making host, port, user and password nil when there is no authority.

As this is breaking the API, this needs to happen before the 1.0 release.

This raises the question: What to do with OFURLHandler? Will it become OFURIHandler? How would a URI be handled? Is it desirable to handle a URI? Would objfw-embedded:///some_file become objfw-embedded:some_file?

URLs know how to locate something, but URIs don't. But theoretically a handler could even know how to retrieve it without a location, hence OFURIHandler would make sense?

Renaming OFURL to OFURI has been done in e7ab06503c.

Dropping fragment was obviously a brain fart. What I meant was dropping parameters, but those were already dropped before. I shouldn't write tickets when tired.

Some more things that should be changed:

• Normalization should strip leading . or .. from paths. RFC 3986 specifies that a path of /../foo should be normalized to /foo, see section 5.4.1.
• An empty authority should lead to an empty host and not a n`l host, as a nil host would mean no authority.
• The file: scheme should treat no authority the same way as an empty authority as per RFC 8089 section 2.
• Since file:/some/path is nicer to read to file:///some/path, it can be considered to switch using no authority instead of an empty authority when using fileURIWithPath:.
• Since the objfw-embedded: scheme is not really hierarchical, it should be changed to not use an authority and not start paths with /, so that it can be treated as opaque.

URI parsing is now implemented (c75059a52f), as well as not using nil when the host is empty.

However, parsing of relative URIs is not according to RFC 3986 yet.

• file: and of-embedded: (new name for objfw-embedded:) didn't need any changes to accept URIs without an authority, so they just work in the desired way.
• URI differentiating between empty and nil host automatically made it create file URIs without an authority (file:/foo instead of file:///foo).

This means only the normalization and handling of relative URIs needs to be changed to comply with RFC 3986.

Relative URIs as per RFC 3986 have been implemented in 3b2697b2a7. This completes URI support.