ObjFW  View Ticket

2022-10-11
00:23 Fixed ticket [44ec7f4c75]: Add support for URIs plus 4 other changes artifact: ebc6c953a2 user: js
2022-10-03
19:57 Ticket [44ec7f4c75]: 3 changes artifact: 869dce6b19 user: js
00:47 Ticket [44ec7f4c75]: 3 changes artifact: 8e35b34057 user: js
2022-10-02
18:04 Ticket [44ec7f4c75]: 3 changes artifact: 72446a5dd3 user: js
2022-09-28
22:13 Ticket [44ec7f4c75]: 3 changes artifact: c55e4c05d1 user: js
19:37 Ticket [44ec7f4c75]: 4 changes artifact: 6b33ad93e7 user: js
2022-09-27
23:36 New ticket [44ec7f4c75]. artifact: c474b13923 user: js

Ticket UUID: 44ec7f4c75ca9ef75dc9ed85cb9da4144e8eeb68
Title: Add support for URIs
Status: Fixed Type: Enhancement
Severity: Severe Priority: High
Subsystem: Resolution: Fixed
Last Modified: 2022-10-11 00:23:29
Version Found In: Milestone: 1.0
User Comments:
js added on 2022-09-27 23:36:28:

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.


js added on 2022-09-28 19:37:13:

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?


js added on 2022-09-28 22:13:40:

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.


js added on 2022-10-02 18:04:11:

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.

js added on 2022-10-03 00:47:36:

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.


js added on 2022-10-03 19:57:37:
  • 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.


js added on 2022-10-11 00:23:29:

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