Wikipedia Diskussion:Lua/Modul/URL

Vorlagenprogrammierung	Diskussionen	Lua			Unterseiten
		Modul	Deutsch	English	Modul:	Dokumentation

nic.

„Wenn ein Domänenname nur aus einer TLD besteht, wird die Adresse zu "nic." + TLD erweitert.“ – warum wird dies gemacht? --ɱ 13:12, 21. Jan. 2023 (CET) PS: davon abgesehen ist der Quellcode durch fast fehlende Kommentierung durch Dritte unwartbar

1. Die Erweiterung auf die Adresse des entsprechenden NIC geschieht, weil der für die TLD verantwortlich ist. Ziel sollte sein, dass jede gültige Domäne auch erreichbar ist.
2. Das Modul ist erkennbar noch nicht vollständig. Dass die Dokumentation vervollständigt wird, ist mein Ziel.

--Vollbracht (Diskussion) 22:07, 21. Jan. 2023 (CET)

„weil der für die TLD verantwortlich ist.“? erstens kommt da stellenweise blödsinn raus:

1. Dreamhost, Hosting-Anbieter oder z.B.:

$ host nic.uk 
nic.uk mail is handled by 5 rav.nic.uk. 
nic.uk mail is handled by 10 mxa.nic.uk. 
nic.uk mail is handled by 10 mxb.nic.uk.

2. der eigentliche Punkt, tippe mal in eine Shell host com oder host de und lese dir die Ausgabe durch. Denke anschließend über den Satz „Ziel sollte sein, dass jede gültige Domäne auch erreichbar ist.“ nach. --ɱ 01:14, 22. Jan. 2023 (CET)

Was schlägst Du vor? --Vollbracht (Diskussion) 01:21, 22. Jan. 2023 (CET)

RFCs lesen und verstehen, bevor man solche Module programmiert. Ein nic. hinzuzufügen ist Frickelei³ am Standard vorbei, dies sollte komplett entfernt werden. Dann ist die Benennung fehlerhaft und der Aufbau, den du gewählt hast. Ein Anfang zum besseren Verständnis wäre Uniform Resource Identifier#Aufbau sowie das obsolete Uniform Resource Locator#Beispiele und natürlich https://www.rfc-editor.org/rfc/rfc3986 --ɱ 02:02, 22. Jan. 2023 (CET)

Ich hab mal ChatGPT den Code analysieren lassen:

Sure, below is a list of potential issues with the provided code:

• The function service:new(link) does not handle invalid URLs and returns nil without providing any error message.
• The method format has some issues in processing format strings, it doesn't check if the placeholders in the format string are actually valid fields of the URL object.
• The code doesn't provide a way to modify the URL object after it is created, for example, by using a set or update method.
• The function service:new(link) uses string manipulation and regular expression to parse the URL into the fields protocol, server, domain, TLD, subdomain, path, file, parameters, and portion and it may have issues if the structure of the URLs is not as expected or there is no regularity in the URL.
• The code uses some regular expressions to parse the URLs, but it does not guarantee that it can recognize and parse all valid URLs as specified in the RFC 3986.
• The code divides the URLs into fields such as protocol, server, domain, TLD, subdomain, path, file, parameters, and portion, but these fields are not all defined in the RFC 3986.
• The code does not handle invalid URLs as specified in the RFC 3986, it does not provide any error handling mechanism.
• The list eTLDs may not be complete, so it may not be able to identify all valid TLDs.
• The relative() method is mentioned as to-be-implemented but not defined in the code.
• The code does not handle internationalized domain names(IDNs) and punycode correctly.
• The code does not handle IPv6 addresses correctly.
• The code does not handle userinfo and fragment parts in the URLs correctly.
• The code does not handle relative URLs correctly.

It's important to note that this is not an exhaustive list and there may be other issues present in the code. It's recommended to thoroughly review and test the code before using it in a production environment. --ɱ 01:04, 23. Jan. 2023 (CET)

@Vollbracht: wirst du die Fehler beheben? --ɱ 18:37, 1. Feb. 2023 (CET)

1. Es steht Dir frei, die Funktionalität des Moduls dahingehend zu erweitern, eventuelle Fehlermeldungen als zweiten Rückgabewert zu entwerfen und zu implementieren, wenn Du eine Anwendung hast, die davon profitiert.
2. Die format()-Methode tut genau das, was sie soll. Wenn ein Wert übergeben wird, der kein Feldname ist, wird dieser als konstantes Label interpretiert.
3. Es gibt viele Bereiche, in denen einmal erzeugte Objekte als unveränderlich gelten. Wenn Du eine Anwendung hast, in der eine Funktionalität zur nachträglichen Änderung des Objektes benötigt wird, steht dem aber nichts im Weg.
   Ich weise darauf hin, dass die Einschätzung Deiner Experten in diesem Punkt falsch ist. Eine Kapselung, wie in anderen OOP-Sprachen existiert hier nicht und ich lehne sie in diesem Umfeld auch ab. Methoden, die die Manipulation unter Vermeidung erwartbarer Fehler übernehmen können, können aber gerne entwickelt werden, wenn Du meinst, sie zu benötigen.
4. Der derzeitige Einsatz des Moduls leidet nicht darunter, dass unbekannte Probleme auftreten könnten. Ich schlage aber vor, dass mögliche Probleme benannt werden, um den möglichen Einsatzbereich zu erweitern.
5. Eine bessere Anpassung an die RFC 3986 begrüße ich.
6. Im Sinne einer Vermeidung der Fehlleitung von Anwendern durch manipulierte URL-Strings (RFC 3986, z. B. Kapitel 3.1) diskutiere ich gerne darüber, wo durch den Einsatz so etwas begünstigt wird und welche Einschränkungen gegenüber manueller Link-Kodierung dieses Modul sicherer machen könnte und sollte, als die manuelle Kodierung es ist. Vielleicht fällt Dir dazu ja etwas ein.
7. Eine Einschränkung im Umgang mit Punycode kann ich derzeit nicht erkennen. Aber eine Verbesserung des Umgangs damit erscheint mir sinnvoll. Ich werde das vermutlich demnächst mal angehen. Magst Du dazu eine Spezifikationsforderung vorschlagen?
8. IP-Adressen (IP4, oder IP6) sind nicht Gegenstand dieses Moduls. Ich schlage vor, das auch so zu belassen. Du kannst aber gerne begründen, warum wir das anders halten sollten.
9. Eine Optimierung des Umgangs mit relativen URLS sehe ich als notwendig an. Derzeit sehe ich die Möglichkeit, dass der derzeitige Code bestimmte relative URLs als absolut missdeuten könnte. Ich habe das noch nicht überprüft. Du kannst Dir ja mal ein Beispiel ausdenken.

In der derzeitigen Version ist dieses Modul geeignet, sinnvolle Eingaben für einen gegebenen Einsatzzweck zu verarbeiten. Das tut es gut. Es für weitere Einsatzzwecke zu härten kann sinnvoll sein. Vielleicht magst Du angeben, wo Du es einsetzen möchtest. Dann können wir über weitere Maßnahmen reden.

Ich freue mich über jede vorgeschlagene Erweiterung der Spezifikation und unterstütze gerne die Weiterentwicklung. Eine neue Version mit erweiterter Funktionalität darf natürlich erst veröffentlicht werden, wenn sie zumindest die bisherige Spezifikation weiterhin einhält und keine unerwartete Änderung ohne vorherige Überprüfung der Kompatibilität mit bestehenden Anwendungen an den bisherigen Schnittstellen vornimmt. --Vollbracht (Diskussion) 03:03, 2. Feb. 2023 (CET)

Danke für deine Auskunft. Wie siehst du die problematische Ergänzung von nic.? --ɱ 07:57, 2. Feb. 2023 (CET)

Wird gelöscht. Wenn eine URL nur aus TLD besteht, wird der Spezifikation folgend nil zurück gegeben. --Vollbracht (Diskussion) 14:52, 2. Feb. 2023 (CET)