Kam eine java.net.URL zu einer HashMap und ging als DNS Anfrage wieder heraus

[LimDul]

Siehe

https://twitter.com/i/web/status/1469775366562541571

wenn man von einer java.net.URL einen hashCode berechnet wird unter anderem ein DNS Lookup auf den Host gemacht, Dinge die mich ehrlich gesagt kopfschüttelnd zurück lassen, wie man das für eine gute Idee halten kann.

 

[Blut1Bart]

Du verwechselst da glaube ich etwas.

A) URL ist nicht für die Sicherheit der URLs zuständig. Wenn du eine Integritäts- und Validitätsprüfung brauchst, solltest du andere Libs verwenden. Zudem kannst du ne String-Map verwenden, wenn du unsichere Strings speichern möchtest, edit: und lazy initialisation betreiben möchtest.

B) Das Problem besteht auf Seiten von JavaScript und Co. Java kann dafür relativ wenig...

 

[LimDul]

Du verwechselst da glaube ich etwas.

A) URL ist nicht für die Sicherheit der URLs zuständig. Wenn du eine Integritäts- und Validitätsprüfung brauchst, solltest du andere Libs verwenden. Zudem kannst du ne String-Map verwenden, wenn du unsichere Strings speichern möchtest, edit: und lazy initialisation betreiben möchtest.

B) Das Problem besteht auf Seiten von JavaScript und Co. Java kann dafür relativ wenig...

Nein, wenn du auf einer java.net.Url Klasse die hashCode Methode aufrufst, wird ein DNS Lookup gemacht.

Beispiel:

package de.limdul.javaforum;

import java.net.MalformedURLException;
import java.net.URL;

public class TestLookup {

    public static void main(String[] args) throws MalformedURLException {
        URL url = new URL("http://localhost");
        URL url2 = new URL("http://127.0.01");
        System.out.println(url.hashCode());
        System.out.println(url2.hashCode());

        url = new URL("http://www.spiegel.de");
        url2 = new URL("http://128.65.210.183");
        System.out.println(url.hashCode());
        System.out.println(url2.hashCode());
        System.out.println(url.equals(url2));
    }
}

Ausgabe:

2133919961
2133919961
-2139956337
-2139956337
true

Kann man auch schön im Source Code des JDK sehen - hashCode macht einen DNS Request...

 

[LimDul]

Weiterer Proof:

package de.limdul.javaforum;

import java.net.MalformedURLException;
import java.net.URL;
import java.time.LocalDateTime;

public class TestLookup2 {

	public static void main(String[] args) throws MalformedURLException {
		URL url = new URL("http://sgihlsghisghkskhljgshklgshlkgslkghskgs");
		System.out.println(LocalDateTime.now());
		url.hashCode();
		System.out.println(LocalDateTime.now());
	}
}

Ausgabe:

2021-12-13T22:01:15.931666400
2021-12-13T22:01:16.957617700

1 Sekunde Laufzeit für hashCode();

Ich hab einen eigenen DNS (pihole) im Netzwerk, schauen wir mal in die Logs:

 

[Blut1Bart]

Nein, wenn du auf einer java.net.Url Klasse die hashCode Methode aufrufst, wird ein DNS Lookup gemacht.

Du hast meinen Beitrag glaube ich nicht verstanden. Ich habe nicht geschrieben, dass das nicht geschieht. Ich habe dir Alternativen aufgezeigt und weshalb das keine unerwünschten Nebenwirkungen sind...

 

[LimDul]

Es verletzt den contract von Equals und hashcode und ist mehr als unerwartet

 

[Blut1Bart]

URL steht für Uniform Resource Locator, diese kann vielgestaltig sein... ich sehe da keine Kontraktsverletzung. Eine IP ist eindeutig...

edit: Diese muss eindeutig sein, meinte ich

 

[LimDul]

Zwei Objekte, wo equals true liefert müssen den gleichen hashcode haben. Das ist hier nicht garantiert, da der hashcode von der IP des hosts abhängig ist. Und Zu einem host kann es beliebig viele ips geben

 

[kneitzel]

Die Verletzung des Kontrakts ist relativ einfach aufzuzeigen:

Du nimmst einen DNS Namen, den du ändern kannst. Machst eine URL damit, nimmst den HashCode. Dann passt du die IP an, machst erneut eine URL mit gleichem Wert und erstellst erneut den Hashcode:

Nun solltest du für die gleiche URL zwei unterschiedliche Hashcodes haben.

 

[LimDul]

Bzw der hängt auch davon ab ob das Netzwerk erreichbar ist. Das ist auf so vielen Ebenen kompletter bullshit....

 

[Blut1Bart]

Ich habe dir Alternativen aufgezeigt.

Zwei Objekte, wo equals true liefert müssen den gleichen hashcode haben. Das ist hier nicht garantiert, da der hashcode von der IP des hosts abhängig ist. Und Zu einem host kann es beliebig viele ips geben

Doch das ist garantiert, dass equals und hashCode übereinstimmen, dafür sind IPs da.

 

[thecain]

Ein Dns/URL Eintrag kann aber auf mehrere IPs zeigen

 

[X5-599]

Die Verletzung des Kontrakts ist relativ einfach aufzuzeigen:

Du nimmst einen DNS Namen, den du ändern kannst. Machst eine URL damit, nimmst den HashCode. Dann passt du die IP an, machst erneut eine URL mit gleichem Wert und erstellst erneut den Hashcode:

Nun solltest du für die gleiche URL zwei unterschiedliche Hashcodes haben.

So wie ich das verstehe sollte dann die URL ebenfalls nicht mehr als gleich angesehen werden, da in equals ebenfalls Nameresolution betrieben wird.

 

[kneitzel]

So wie ich das verstehe sollte dann die URL ebenfalls nicht mehr als gleich angesehen werden, da in equals ebenfalls Nameresolution betrieben wird.

Das ist aber nicht Part der URL! Aber das ist halt etwas, das die Entwickler so sehen wie Du (Unabhängig davon, ob ich dem folgen kann oder nicht).

URL (Java SE 17 & JDK 17)

declaration: module: java.base, package: java.net, class: URL

docs.oracle.com

Class URL represents a Uniform Resource Locator, a pointer to a "resource" on the World Wide Web.

Und da wird dann dieser Pointer auch beschrieben incl. dem Host. Und das ist da dann einfach ein Part des Strings.

Equals schreibst dann zwar auch:

Two hosts are considered equivalent if both host names can be resolved into the same IP addresses; else if either host name can't be resolved, the host names must be equal without regard to case; or both host names equal to null.

Since hosts comparison requires name resolution, this operation is a blocking operation.

Note: The defined behavior for equals is known to be inconsistent with virtual hosting in HTTP.

Aber dem kann ich nicht folgen! Die IP Adresse ist aus meiner Sicht eine andere Abstraktionsebene, die bei dem Vergleich nicht wirklich sinnvoll ist.
(Und die IP ist einfach uninteressant! Diese Abstraktionsebene ist ja eben eingeführt wurden, um hier eine Unabhängigkeit zu schaffen! Zu Cloud Zeiten noch viel mehr als früher! Es gibt dynamische Prozesse die ggf. mehr oder weniger Ressourcen zuordnen. Das mag alles gehen, so alles hinter LoadBalancern steckt oder hinter einer "virtuellen" IP, aber dem muss ja nicht so sein! Reicht ja schon, dass ich auf einer kleinen Hand voll Servern Dinge verschiebe von einem Server zu einem anderen. Du bist abhängig von Dingen außerhalb - das ist zumindest nicht mein Verständnis vom equals.

Mein Hauptkritikpunkt ist hier:
a) Es ist einfach überkompliziert. und in meinen Augen nicht intuitiv. (Oder ist das ein erwartetes Verhalten?)
b) Probleme bei der Nutzung: HashCode / equals abhängig von der IP, die außerhalb des Systems liegt. Du speicherst also eine URL als Key in einer HashMap und wirst diese dann nicht mehr aufrufen können, so sich bei der IP etwas geändert haben sollte. (hashCode wird wohl gecached - aber das löst nicht wirklich die Probleme!)
c) Mögliche Probleme bei der Implementation, die dann in Spezialfällen zu Verstößen gegen den Contract führen (Je nach Caching kann man sowas entwerfen. Aber ich revidiere mein Urteil etwas, denn das ist dann kein Verstoß gegen den Kontrakt der durch den Ansatz kommt sondern eben durch einen "Fehler" in der Implementation kommt.)

Also ich bin hier ehrlich gesagt extrem überrascht und kann die Beweggründe hier gerade nicht nachvollziehen.

Ich hatte auch einmal im .Net Bereich geschaut und da ist sowas nicht der Fall. Da läuft es aber auch über die Klasse Uri.

 

[Blut1Bart]

Ich weiß nicht wo das Problem ist... Wenn ich ein Pferd kaufen möchte, so erwarte ich ein Pferd. Wenn ich einen Esel kaufen möchte, so erwarte ich einen Esel...

 

[httpdigest]

Es ist bereits allgemein und landläufig bekannt, dass java.net.URL completely broken ist, da das Ergebnis von hashCode() und equals() eben - wie genannt - von I/O abhängt und z.B. unterschiedliche Ergebnisse liefert, wenn dein Rechner gerade Internetzugriff hat oder nicht.
Die Empfehlung ist hier schon lange, nicht java.net.URL, sondern java.net.URI zu nehmen, welches dieses Problem nicht hat.

 

[Blut1Bart]

Die Empfehlung ist hier schon lange, nicht java.net.URL, sondern java.net.URI zu nehmen, welches dieses Problem nicht hat.

Oder eben String

Ich sehe das Problem in Osi Layer 8 (es entsteht also wieder einmal nur aus Unkenntnis heraus)

 

[httpdigest]

Stimmt. Aber das ist dann vermutlich bei fast jedem Problem die Ursache.
Das eigentliche Problem ist aber Intuition bzw. die extreme Verletzung des "Principle of least astonishment".
Das Verhalten von java.net.URL _erwartet_ man halt einfach nicht.

 

[LimDul]

Und es ist ja auch von sun bestätigt, dass es scheiße ist - man will es nur nicht fixen aus Gründen der backwards compatibility : https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4434494

Nachtrag, Sonar behandelt es auch als Major Problem: https://rules.sonarsource.com/java/RSPEC-2112