Hacker News Reader

Comment by jefftk | Hacker News Reader

I see why this was useful, though it still wasn't a good idea. This looks like it was added in ~1995, at which point (a) it was common for multiple hostnames to refer to the same server and (b) they were guaranteed to act identically because there was no HOST: header yet.

View on HN

Your b) was actually only ever true for the HTTP protocol, but URLs are not strictly limited to that protocol. They are not limited to any finite set of protocols at all. You could easily make up your own protocol which differentiates between host names in a similar way as modern HTTP does. And you could have made that in 1995.

You could have made one in 1995, but looking over https://www.iana.org/assignments/protocol-numbers/protocol-n... I think HTTP/1.1 was the first protocol to send the host name like this. (Though I could be missing something, since that's a lot of protocols.)

Your 'a' case is still common.

Perversely, a well-timed DNS record update and cache expiry could make a URL not-equal to another URL made from the same string of characters.

That's the essence of a DNS rebinding attack, which can be used to bypass server-side request forgery vulnerability mitigations.

I might be wrong, it was a long time ago, but IIRC a different DNS rebinding attack was actually part of the reason this behavior was introduced to the URL class, to help protect against such attacks in Java Applets.

Hell, no need for a record update: just multiple A records for the same hostname, with a short enough TTL that two different URL instances could conceivably resolve differently.

Reply on news.ycombinator.com