JSON-Validator und Formatierer

Der JavaScript Object Notation, kurz JSON, sind viele Entwickler sicherlich schon einmal über den Weg gelaufen. Bei der Arbeit mit JSON-Daten tritt ab und an der Fall auf das Daten für einen Test validiert oder sinnvoll formatiert werden sollen.

Der JSON Formatter & Validator von Curious Concept

Im Web existieren unterschiedlichste JSON-Validatoren und Formatierer, allerdings mit eher schwankender Qualität. Einer der Validatoren, welcher heraussticht ist der JSON Formatter & Validator von Curious Concept. Er kann JSON-Daten nach den unterschiedlichsten Standards (RFC 8259, RFC 7159, RFC 4627 und ECMA-404) validieren und anhand unterschiedlichster Templates formatieren. Zu finden ist der Validator unter jsonformatter.curiousconcept.com.

Maximale URL-Länge bei HTTP

Der Uniform Resource Locator, oder in der Kurzform die URL, wird sicherlich jedem schon begegnet sein. Die URL setzt sich aus einem Schema und einem für das Schema spezifischen Part zusammen. Getrennt werden die beiden Bestandteile durch einen Doppelpunkt. Bei HTTP wäre die Angabe des Schemas (http) und dem anschließenden spezifischen Teil mit dem Host, eventuellen Informationen über den Port, Kennwörter und ähnliches und anschließend der Pfad zur gewünschten Ressource. Interessant ist allerdings die Frage, wie lang darf eine solche URL sein? Kurze URLs wie:

http://api.example.com

machen keinerlei Probleme. In der RFC 2616 finden sich erste Anhaltspunkte dazu. Die RFC trägt den Namen Hypertext Transfer Protocol — HTTP/1.1 und definiert eben dieses Protokoll. Im Abschnitt 3.2, der sich um Uniform Resource Identifiers dreht, findet sich im Unterpunkt 3.2.1 folgender Abschnitt:

The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15).

Aus diesem Abschnitt ergibt sich das URLs so lang wie benötigt sein dürfen und das HTTP-Protokoll keinerlei Beschränkung vornimmt. Sollte der Server eine lange URL nicht verarbeiten können, so soll dieser mit dem Statuscode 414 (URI Too Long) antworten. Gleich danach finden sich ein weiterer Hinweis in der RFC:

Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths.

Dort wird darauf hingewiesen das es Probleme geben kann, wenn die URL länger als 255 Byte ist. Je nach Kodierung und Sprache (wie z.B. Deutsch oder Japanisch), lassen sich eine unterschiedliche Menge an Informationen in diesen 255 Byte kodieren. Allerdings wurde die RFC 2616 durch die RFC 7230 für obsolet erklärt. In dieser RFC findet sich folgender Absatz:

Various ad hoc limitations on request-line length are found in practice. It is RECOMMENDED that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets.

Mit diesem Absatz wird definiert das HTTP-Clients und Server eine Mindestlänge von 8000 Byte unterstützen sollen. In der Praxis stellt sich nun die Frage was wirklich funktioniert. Es existieren durchaus längere URLs, z.B. sogenannte Data-URLs, allerdings sind dies keine HTTP-URLs, sondern definierten ein eigenes Schema. Daneben existieren alte Untersuchungen zu dem Thema. Unabhängig von der theoretischen Machbarkeit existieren weitere Kriterien, wie die maximale Länge die von Suchmaschinen indiziert werden. Hier schwanken die Zahlen zwischen knapp 1800 Byte bis zu 2048 Byte.

Damit lässt sich die Frage nach der maximalen URL-Länge nicht pauschal beantworten. Mit aktueller Software auf Server- und Client-Seite, sollten 1024 Byte für die URL kein Problem sein. Längere URLs sollten mit Vorsicht genossen werden und ihre Sinnhaftigkeit noch einmal hinterfragt werden.

Example gefällig?

Immer wieder sieht man es dass man Mails von der Adresse “noreply@noreply.com” bekommt oder in irgendwelchen Dokumentationen Adressen nach dem Schema “irgendwer@irgendwo.com” oder “keine@vorhanden.de” aufgeführt sind. Das Problem an solchen Angaben ist, das sie sehr schlechte Beispiele sind. Wenn ich z.B. als Firma meine Bestellbestätigungen mit “noreply@noreply.com” als Absender abschicke und der Kunde doch antworten sollte, so hat der Eigentümer der Domain “noreply.com” plötzlich ein paar sehr interessante Informationen bekommen.

Gegen Dinge wie “noreply@seeseekey.net” ist nicht einzuwenden, so lange man Eigentümer der Domain ist. Wenn man das ganze nur als Beispiel oder zur Veranschaulichung dient so sollte man eine dieser Domains benutzen:

  • example.com
  • example.net
  • example.org
  • example.edu

Diese Domains sind durch die RFC 2606 als Beispieldomains reservieren und man kann sich auch darauf verlassen, das dies auch in der Zukunft so bleibt.

Weitere Informationen gibt es unter:
http://de.wikipedia.org/wiki/Example.com