4 ms·

Wait, seriously? Did whoever designed that have any idea what URLs actually were? Even without DNS, comparing the hosts is no way to compare URLs. I can't thi

by franga2000 7y ago

Wait, seriously? Did whoever designed that have any idea what URLs actually were? Even without DNS, comparing the hosts is no way to compare URLs. I can't think of a single example of two 'equal' URLs whose strings don't match (up until the parameters, at least)...

matthewmacleod 7y ago
Yes - bear in mind the URL class has been around since 1995, when the landscape was somewhat different! At that point, URLs resolving to the same IP were considered equal, even if the host names were different. Even now, there’s no real difference between say “http://example.com” http://example.xn--com-9o0a and “http://example.com:80”; http://example.com:80”; it would have been reasonable to consider these equal.
twic 7y ago
http://internalserver/resource http://internalserver/resource http://internalserver.initech.com/resource http://internalserver.initech.com/resource
- franga2000 7y ago
  Those are certainly not equivalent, as the 1st would not even resolve in the majority of environments. I'm assuming the 2nd host is a reverse proxy for the 1st? Unless that fact is part of your design assumptions (which it certainly can't be for a general URL class in a standard library), those should be considered different.
  - twic 7y ago
    If the two hostnames resolve to the same IP address, they are equivalent. This could happen if initech.com was a default domain. This is a very standard situation in internal networks which i am surprised you are not familiar with.
    - franga2000 7y ago
      I am quite familiar with that kind of setup and it's even further from equivalent than what I assumed you were referring to. Shared web hosting is the common example, but some other protocols are capable of distinguishing between hostnames. google.com and maps.google.com resolve to the same address but are not equivalent. Even if your example and many others are equivalent, there are many that aren't. A general library should not make assumptions like that, unless they hold 100% of the time.
      - twic 7y ago
        You asked for a single example of two 'equal' URLs whose strings don't match up, and now you've got one.
        franga2000 7y ago
        Looking back, I did phrase it ambiguously. What I meant was two URLs that are equal by definition, (no matter the server config, assuming standards compliance). A (general) library should make no more assumptions than the standard it implements. What I was asking about were cases, similar to http://h/p?x1=a&x2=b http://h/p?x1=a&x2=b being equal to http://h/p?x2=b&x1=a http://h/p?x2=b&x1=a since query parameter order is defined to not matter. The spec I am mostly familiar with is, however, rather new, and whatever standard controlled URLs at the time (if any) might have made more assumptions.
benibela 7y ago
How about http://localhost http://localhost http://::1 http://::1 and http://0:0:0:0:0:0:0:1 http://0:0:0:0:0:0:0:1 ?

matthewmacleod 7y ago

Yes - bear in mind the URL class has been around since 1995, when the landscape was somewhat different! At that point, URLs resolving to the same IP were considered equal, even if the host names were different. Even now, there’s no real difference between say “http://example.com” http://example.xn--com-9o0a and “http://example.com:80”; http://example.com:80”; it would have been reasonable to consider these equal.

twic 7y ago

http://internalserver/resource http://internalserver/resource http://internalserver.initech.com/resource http://internalserver.initech.com/resource

franga2000 7y ago
Those are certainly not equivalent, as the 1st would not even resolve in the majority of environments. I'm assuming the 2nd host is a reverse proxy for the 1st? Unless that fact is part of your design assumptions (which it certainly can't be for a general URL class in a standard library), those should be considered different.
- twic 7y ago
  If the two hostnames resolve to the same IP address, they are equivalent. This could happen if initech.com was a default domain. This is a very standard situation in internal networks which i am surprised you are not familiar with.
  - franga2000 7y ago
    I am quite familiar with that kind of setup and it's even further from equivalent than what I assumed you were referring to. Shared web hosting is the common example, but some other protocols are capable of distinguishing between hostnames. google.com and maps.google.com resolve to the same address but are not equivalent. Even if your example and many others are equivalent, there are many that aren't. A general library should not make assumptions like that, unless they hold 100% of the time.
    - twic 7y ago
      You asked for a single example of two 'equal' URLs whose strings don't match up, and now you've got one.
      - franga2000 7y ago
        Looking back, I did phrase it ambiguously. What I meant was two URLs that are equal by definition, (no matter the server config, assuming standards compliance). A (general) library should make no more assumptions than the standard it implements. What I was asking about were cases, similar to http://h/p?x1=a&x2=b http://h/p?x1=a&x2=b being equal to http://h/p?x2=b&x1=a http://h/p?x2=b&x1=a since query parameter order is defined to not matter. The spec I am mostly familiar with is, however, rather new, and whatever standard controlled URLs at the time (if any) might have made more assumptions.

benibela 7y ago

How about http://localhost http://localhost http://::1 http://::1 and http://0:0:0:0:0:0:0:1 http://0:0:0:0:0:0:0:1 ?