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.
On 10/14, Jens Alfke wrote:
> > On Oct 14, 2016, at 10:20 PM, Keith Smiley <k...@keith.so> 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.)
swift-users mailing list