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.

REST-APIs unter Apache und Nginx betreiben

Eine der wesentlichen Eigenschaften von REST-APIs bzw. RESTful-Webservices ist ihre Adressierbarkeit von Ressourcen. Wenn ich z.B. über eine API verfüge, welche mir Namen generiert, so kann es in dieser API unterschiedliche Ressourcen geben:

GET https://api.example.com/name/german/
GET https://api.example.com/name/polish/

Rufe ich nun eine der beiden Ressourcen mit dem HTTP-Verb GET auf so erhalte ich entweder einen deutschen oder einen polnischen Namen von dieser Beispiel-API. Für den Webserver ergibt sich allerdings das Problem, das der Ordner name und die entsprechenden Unterordner nicht existieren. Das einzige was in diesem Beispiel existiert ist eine index.php-Datei, welche unter der URL:

https://api.example.com/index.php

zu finden ist. Damit die REST-API ordnungsgemäß funktioniert, müssen die entsprechenden Aufrufe zur index.php-Datei umgebogen werden. Bei dem Webserver Apache kann dies über eine .htaccess-Datei mit folgendem Inhalt erledigt werden:

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^(.*)$ index.php?_url=/$1 [QSA,L]
</IfModule>

Diese Datei sollte dabei im gleichen Verzeichnis wie die Datei index.php liegen. Bei Nginx muss stattdessen die Konfiguration der Domain bzw. der Seite angepasst werden. Diese Konfigurationen sind unter /etc/nginx/sites-available/ zu finden. Dort muss folgende Konfiguration hinzugefügt werden:

try_files $uri $uri/ @rewrite;

location @rewrite {
	   rewrite ^/(.*)$ /index.php?_url=/$1;
}

Hinterlegt werden muss die Konfiguration in einem server-Block derselben. In diesem Fall würde die URL bzw. der Aufruf:

GET https://api.example.com/name/german/

intern in die URL:

https://api.example.com/index.php?_url=name/german/

umgeschrieben und vom Webserver geladen. Dadurch landen die Aufrufe wieder bei der Datei index.php und können verarbeitet werden.

curl zur Abfrage von REST-APIs benutzen

Die Aufgabe des freien Kommandozeilentools curl ist einfach beschrieben: Datentransfer. So unterstützt curl unterschiedlichste Protokolle wie FTP, HTTP, HTTPS, IMAP, SCP, SMB und viele mehr. Ein einfacher Download einer Datei über HTTP bzw. HTTPS würde mit curl wie folgt aussehen:

curl -O https://example.com/file.zip

Auch ein Transfer z.B. per FTP ist kein Problem:

ftp://example.com/file.zip

Allerdings beherrscht curl wesentlich mehr Operationen als nur das Herunterladen von Dateien. So kann curl genutzt werden, um REST-APIs zu benutzen. Diese APIs arbeiten nicht nur mit dem HTTP-Verb GET, sondern auch mit anderen Verben wie POST und PUT. Ein einfacher GET-Request wurde mittels curl wie folgt aussehen:

curl -X GET https://example.com/

Ein POST-Request wird auf die gleiche Art durchgeführt:

curl -X POST https://example.com/

Sollen zusätzlich Daten übertragen werden, so geschieht dies mit dem Parameter -d:

curl -X POST https://example.com/  -d '{
	field: "data",
	field2: "data",
	field3: "data"
}'

Damit werden die Daten im Body des Requests mitgesendet. Auch die Übergabe von Headern ist mittels curl möglich:

curl -X POST https://example.com/ 
 -H 'HeaderField: headerValue'
 -d '{
	field: "data",
	field2: "data",
	field3: "data"
}'

Manche APIs und andere Services blockieren Abrufe über curl manchmal. Dabei wird der Useragent von curl ausgesperrt. Allerdings kann dieser einfach geändert werden:

curl -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0" -X GET https://example.com/

Damit können solche fragwürdigen Maßnahmen, welche zum Ausschluss von curl führen, umgangen werden. Daneben verfügt curl über viele weitere Operationen bzw. Optionen. So kann z.B. mittels des Parameters -I nur der Header des Response bezogen werden:

curl -I -X GET https://example.com

Somit bietet curl die entsprechende Funktionalität um REST-APIs für Tests und ähnliches flexibel abzufragen.

Nachkommastellen von Pi als REST-Service

Die Zahl Pi beschreibt das Verhältnis des Umfangs eines Kreises zu seinem Durchmesser und gehört sicherlich zu den bekannteren mathematischen Konstanten. Anlässlich des Pi-Days am 14. März 2019 veröffentlichte Google die Zahl Pi mit bisher unerreichten 31,4 Billionen Nachkommastellen.

3.1415926535897…

Passend dazu stellte Google die Seite pi.delivery in Netz. Neben einigen Spielereien rund um Pi, wie die Nutzung von Pi zur Generierung von Musik, findet sich dort eine REST-API, mit welcher die Nachkommastellen von Pi erfragt werden können. Ein einfacher Request des Services sieht wie folgt aus:

GET https://api.pi.delivery/v1/pi?start=0&numberOfDigits=42

Für den Request existieren zwei Parameter. Der erste Parameter mit dem Namen start definiert ab welcher Stelle die Nachkommastellen geliefert werden sollen. Der zweite Parameter numberOfDigits setzt die Anzahl der zurückgelieferten Nachkommastellen. Als Antwort erhält der Nutzer des Service anschließend die entsprechenden Nachkommastellen (sowie die 3 am Anfang von Pi):

{
    "content": "314159265358979323846264338327950288419716"
}

Maven-Repository in Eigenregie hosten

Wenn mittels Maven eine Abhängigkeit zur pom.xml-Datei, wie in folgendem Beispiel, hinzugefügt wird:

<dependency>
	<groupId>org.slf4j</groupId>
	<artifactId>slf4j-api</artifactId>
	<version>1.7.26</version>
</dependency>

versucht Maven diese Abhängigkeit von Maven Central, dem zentralen Repository, zu beziehen. Es ist allerdings möglich Abhängigkeiten aus anderen Repositories zu beziehen. Dazu muss der repositories-Block zur pom.xml hinzugefügt werden.

<repositories>
	<repository>
		<id>example</id>
		<url>https://repository.example.org</url>
	</repository>
</repositories>

Aus Nutzersicht ist die Konfiguration von Maven damit erledigt. Soll ein solches Maven-Reposity aufgesetzt werden, ist dies relativ einfach möglich. Dazu wird ein Verzeichnis per HTTP über den Webserver Nginx ausgeliefert. Innerhalb dieses Verzeichnisses wird ein gesicherter Ordner erstellt, welcher über WebDAV erreicht werden kann. Die entsprechende Nginx-Konfiguration sieht für diesen Fall wie folgt aus:

server {
        listen   443 ssl;
        listen [::]:443 ssl;

        ssl_certificate /etc/letsencrypt/live/repository.example.org/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/repository.example.org/privkey.pem;

        root /var/www/example/repository;

        server_name repository.example.org;

        location / {
                autoindex     on;
        }

        location /upload {
                dav_methods     PUT DELETE MKCOL COPY MOVE;
                dav_ext_methods   PROPFIND OPTIONS;

                dav_access    user:rw group:rw all:rw;

                create_full_put_path  on;

                autoindex     on;

                auth_basic "restricted";
                auth_basic_user_file /var/www/example/repository/upload/.htpasswd;
        }
}

Die .htpasswd-Datei, welche für die Authentifizierung benötigt wird, kann mit dem Tool htpasswd erstellt werden:

htpasswd -c .htpasswd nutzer1

Bei der Nutzung wird das gewünschte Passwort erfragt. Soll ein weiterer Nutzer hinzugefügt werden, so muss der Parameter -c entfernt werden:

htpasswd .htpasswd nutzer2

Anschließend wird die Konfiguration von Nginx mittels:

service nginx reload

aktualisiert. Danach kann WebDAV für die Ressource verwendet werden. In der pom.xml-Datei für das Projekt, welches ein Artefakt für das Repository erzeugt, wird der build-Bereich erweitert und der distributionManagment-Bereich hinzugefügt:

            </plugin>
        </plugins>
        <extensions>
            <extension>
                <groupId>org.apache.maven.wagon</groupId>
                <artifactId>wagon-webdav-jackrabbit</artifactId>
                <version>3.2.0</version>
            </extension>
        </extensions>
    </build>
    <distributionManagement>
        <repository>
            <id>example</id>
            <url>dav:https://repository.example.org/upload/</url>
            <layout>default</layout>
        </repository>
    </distributionManagement>
</project>

Im Extension-Bereich wird das Wagon-Plugin für WebDAV aktiviert. Dieses sorgt dafür das die Artefakte per WebDAV zum Repository hochgeladen werden. In dem distributionManagment-Bereich wird die WebDAV-URL definiert. Wenn nun ein:

mvn deploy

durchgeführt wird, wird dies allerdings nicht funktionieren. Hintergrund ist das der upload-Ordner per Basic authentication geschützt ist. Die Zugangsdaten für diese Authentifikation müssen noch hinterlegt werden. Natürlich werden diese nicht in der pom.xml hinterlegt, da dies aus Gründen der Sicherheit keine gute Idee wäre. Stattdessen werden die Daten in der settings.xml hinterlegt. Diese befindet sich im Pfad:

~/.m2/settings.xml

In dieser Datei wird eine server-Sektion mit den Zugangsdaten hinzugefügt:

<settings>
	<servers>
		<server>
			<id>example</id>
			<username>example</username>
			<password>password</password>
		</server>
	</servers>
</settings>

Anschließend kann das Artefakt erfolgreich mittels:

mvn deploy

in das Repository hochgeladen werden. Problematisch ist das sich die Daten nur im upload-Verzeichnis und nicht im eigentlichen Verzeichnis des Repository liegen. Zur Lösung hierfür wird ein Cronjob, im Kontext des Nutzers www-data, angelegt: 

sudo -u www-data crontab -e

Ziel des Cronjobs ist es die Daten aus dem upload-Verzeichnis regelmäßig in das eigentliche Verzeichnis des Repository zu kopieren:

*/5  *    * * *   cp /var/www/example/repository/upload/* /var/www/example/repository/ -r

Damit wird alle 5 Minuten der Inhalt des uploadVerzeichnisses in das Repository kopiert. Ein Verschieben kann leider nicht durchgeführt werden, da die Metadaten beim jeden Deployment von Maven eingelesen werden und erweitert werden. Hier könnten Optimierungen durchgeführt werden, so das alle Dateien bis auf die Metadaten verschoben werden. Soll ein nicht öffentliches Repository erstellt werden, kann auf den zusätzlichen upload-Ordner verzeichnet werden und das Hauptverzeichnis selber per WebDAV befüllt werden. So lange die Zugangsdaten für den Server in der settings.xml-Datei hinterlegt sind, können seitens Maven die entsprechenden Artefakte bezogen werden.