In our case, if we accidentally send a URL from the server with a trailing slash, we want that to be equivalent to one without. But yea, if you're manipulating it you might have more problems! Although in our case we add the slash for the case without it.
-- Keith Smiley On 10/14, Jens Alfke wrote: > > > On Oct 14, 2016, at 10:20 PM, Keith Smiley <[email protected]> wrote: > > > > FWIW we've overridden URL's equality function in order to get a "more > > realistic" > > result. We lowercase everything and compare the scheme, host, port, and > > query, > > I hope you don’t lowercase everything — the scheme and host are > case-insensitive, but the rest isn’t. > > > along with normalizing the path to handle cases where `/` exists in some > > paths > > but doesn't in others. > > In your example it’s true that “apple.com <http://apple.com/>” and > “apple.com/ <http://apple.com/>“ are equivalent, but in general I don’t think > a URL with a trailing “/“ is equivalent to one without. (For one thing, the > behavior of applying a relative URL is different.) > > —Jens _______________________________________________ swift-users mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-users
