swift-server
Unix Domain Socket URLs are not idempotent
AHC has an interesting quirk with how it supports unix: URLs - if the URL has a baseURL, the path of that base URL is taken as the socket path, and the relative path on top is taken as the path "within" the socket.
Basically it's squishing 2 paths in to the same URL - but not the same URL string, just the URL object. It's just an extremely fragile artefact of Foundation's URL model, and is not idempotent with respect to serialization, the .absoluteURL property, or many of the other modifications people like to make to URLs.
In fact it's so fragile that I'd argue the only way to reliably use this feature is directly in the Request initializer. If that's the case, a new initializer on Request would fulfil that need better (of course, there are also http+unix: URLs if you need to encode the entire request as a URL, and they do not have any of these idempotence issues).
Would it be possible to deprecate and remove the UDS base-path quirk?
Offending code is here - note that the socket path and uri depend on the presence of a base URL.
I have no objection to deprecating it, though we can't immediately remove it. Deprecation will put it on a path to removal at some future point though.
@krzyzanowskim added the patch though, so I'd like his input if he's willing to give it.
I don't have a strong opinion. @karwa mind preparing PR with proposed change maybe?
Deprecation without removal is a little difficult, because there's no particular function or public type to annotate.
What I could perhaps do is log some kind of warning when we detect such a URL, saying that the functionality is deprecated and will be removed in a future version, pointing them towards http+unix URLs instead.
The best reason for removal, beside it being so fragile, is that it makes it very hard to move to a new URL type. The latest URL standard doesn't preserve its base URL - you just have a URL, parse a relative string against it, and get a new URL. Idempotence WRT serialisation is crucial, so having state which is not encoded in the string representation would be a huge burden to try to support (for very little gain).
@karwa oops. So this is a little gross but we could just log a logger.warning the first time we see one of those URLs?
