Cookie Notice

As far as I know, and as far as I remember, nothing in this page does anything with Cookies.

2012/02/14

"Bug" affecting Safari browsers

Strictly speaking, Safari doesn't have the bug.

Strictly speaking.

Consider this URL: http:/~foo/

It is ugly, isn't it? This showed up in our workflow, not from code I wrote, and when I objected to it, my co-worker said the browser renders it (meaning, if the page with this janky URL on it is on http://server.org/, the browsers we used (Chrome, to be specific) would tell we meant http://server.org/~foo/ and act accordingly.

There are generally two ways of presenting URLs. Absolute: http://server.org/~foo/ , and relative: /~foo . Let me step back from that, because, beyond the server and protocol aspect, /~foo is far more absolute than ../foo. So I don't know what to call /~foo/. And I couldn't dig through the RFCs enough to say "RFC #### says no!" so I had to drop back to "It looks janky".

Because Chrome accepts it.

And Firefox accepts it.

And IE accepts it.

And Opera accepts it.

But one of our user labs is mostly Mac, browsing with Safari, and they had a problem with the page with the janky URLs. They don't know what to do with that sort of URL. I can argue that they shouldn't know what to do with that sort of URL, because nobody should use that janky sort of URL. In fact, I do. The bug was with us being janky with what we send, defying Postel's law. That URL is the reason XML hates the world. But Safari drops the ball in a way other browsers can handle, which bothered our users, who had nothing to do with the issue. This was reason enough for us to code URLs better.

And, it turns out, the default browser on pre-ICS Android phones also hate it.

I am now a registered Apple developer, only so I could get to the bug tracker and report this.

No comments:

Post a Comment