Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-9091] UUID does not follow RFC for string representation #3604

Open
swift-ci opened this issue Oct 26, 2018 · 4 comments
Open

[SR-9091] UUID does not follow RFC for string representation #3604

swift-ci opened this issue Oct 26, 2018 · 4 comments

Comments

@swift-ci
Copy link
Contributor

Previous ID SR-9091
Radar None
Original Reporter benasher44 (JIRA User)
Type Bug
Environment

macOS 10.13.6
Swift 4.2

Additional Detail from JIRA
Votes 1
Component/s Foundation
Labels Bug
Assignee None
Priority Medium

md5: d7b6de109427ac7a4dfcc53d8d5cac3a

relates to:

  • SR-8439 Provide UUID RFC 4122 compliant string

Issue Description:

The RFC for UUID is explicit about the string representation being lowercase:

The hexadecimal values "a" through "f" are output as lower case characters and are case insensitive on input.

But, UUID and NSUUID both return uppercase strings for uuidString, which is then used for UUID's implementation of Encodable and CustomStringConvertible. This makes cross platform issues around case-sensitive storage of UUID s very difficult to completely avoid. For this reason, we're likely going to stop using native UUID in our app and use an internal clone that is the same except it always represents UUID s as lowercase for String representations.

This has been an issue for us for some time, and we now have the time to figure out a more permanent solution to the various workarounds we have in place in our codebase (mostly just avoiding string interpolation with UUID and banning the use of uuidString). Now that Swift is open source and we can see the internals, the change feels pretty straightforward: change the one usage of uuid_unparse to instead be uuid_unparse_lower. But, given the issues we're experience around case-sensitive storage of UUID strings, this feels like a significant breaking change. Additionally, NSUUID's internals would also need to be updated.

I'm happy to make an SE proposal for this, given that I understand the code change in Swift and can present it along with the proposal. That said, there's likely more to do and consider than just that, so I'm starting with this bug 🙂. It would be great to hear from knowledgeable members if this bug is enough, if I should make an SE proposal, or if I should do something beyond that.

Thanks for your consideration!

@lorentey
Copy link
Member

This seems important for interoperability. (Even though the other party is also at fault if they refuse to process uppercase UUIDs.)

Changing UUID.uuidString may still be feasible, as doing that cannot currently cause binary compatibility issues. (Unlike NSUUID.) Source compatibility issues are possible, but limited, since the UUID initializer is case insensitive.

Even if we rule out changing UUID.uuidString, perhaps it would make sense to at least change UUID's Encodable implementation to generate a lowercase encoding.

@swift-ci
Copy link
Contributor Author

Comment by Ben A (JIRA)

Actually the issue we've been having isn't about deserializing uppercase or lowercase strings back into UUIDs. The issue is when multiple platforms save UUID strings of different cases in a shared web API backend. Let's say you have a web API backend that stores UUID strings as the primary key for objects that are created offline on native mobile client (e.g. Android and iOS devices). UUIDs that are the same, but sent to the web API backend from different clients, will not be equal when being compared for a primary key lookup, unless the web API backend is aware of the client-specific differences (Apple devices using uppercase and everyone else using lowercase) and normalizes on one case. Does that help clarify?

@belkadan
Copy link

It sounds super dangerous to change an existing API; if anyone is comparing UUIDs as strings and they happen to all be generated through NSUUID, their code is currently behaving as desired. I suspect Foundation will need to add a new API for this.

@swift-ci
Copy link
Contributor Author

Comment by Ben A (JIRA)

I agree. Are there other types that have taken this kind of migration path? Ideally, there would be some way to opt UUID into using lowercase strings.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants