Kein Zucker mehr für Coca-Cola

Coca-Cola gibt es in der klassischen Variante und in einigen anderen Varianten, wie Coca-Cola Vanilla oder Coca-Cola Cherry. In den letzten Wochen war es allerdings schwer bis unmöglich bestimmte Sorten wie Vanilla und Cherry in der Zucker-Variante zu bekommen. Der Grund dafür ist relativ einfach: sie werden nicht mehr produziert. Das Gleiche trifft auch auf einen Großteil der Fanta-Sorten zu.

Die neue Coca-Cola Vanilla, ohne Zucker

Mittlerweile existieren Petitionen zu dem Thema und ein entsprechender Artikel von Coca-Cola dazu. Dort wird auch erklärt, warum es zu dieser Umstellung kam. So möchte Coca-Cola den Zuckergehalt in seinen Getränken reduzieren. Auf die umzustellenden Produkte bezogen findet sich in dem Artikel folgender Satz:

So werden zukünftig sowohl unsere vielen Fanta Geschmackssorten als auch andere Produkte wie Coca-Cola Cherry und Coca-Cola Vanilla auf die Variante ohne Zucker umgestellt. Deshalb gibt es viele Fanta Sorten nun ausschließlich in der kalorienfreien Variante.

Zusammenfassend ist die klassische Coca-Cola und Fanta, sowie einige andere Produkte noch mit Zucker erhältlich (weshalb die Überschrift des Artikels leicht übertrieben ist), alles andere nur noch ohne. Dafür gibt es stattdessen eine Mischung aus drei Süßstoffen (Aspartam, Acesulfam K und Natriumcyclamat) in den neuen Varianten. Das alles wäre vielleicht noch vertretbar, allerdings reichen die zuckerfreien Sorten nicht an ihre jeweiligen Originale heran. Sie schmecken, gelinde gesagt, überhaupt nicht.

Natürlich ist es lobenswert, wenn weniger Zucker in einem Getränk ist, immerhin sind Coca Cola und Co. wahre Kalorienschleudern, aber das Ersatzprodukt kommt geschmacklich nicht einmal annähernd an das Original heran. Hier muss sich im Laufe der Zeit zeigen ob das die Verkaufszahlen der Produkte auch zeigen und die Coca Cola Copmany eventuell umsteuert und wir besagte Sorten wieder in einer zuckerhaltigen Variante erhalten. Frei dem Motto: der Markt wird es richten.

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.

Composer für PHP nutzen

Composer ist ein Paket- bzw. Dependency-Manager für PHP. Damit ist es möglich die Abhängigkeiten von PHP-Projekten komfortabel zu verwalten und aktuell zu halten. Dazu wird in dem Projekt eine Datei mit dem Namen composer.json angelegt. In dieser Datei finden sich die Abhängigkeiten für das Projekt:

{
  "minimum-stability": "RC",
  "require": {
    "slim/slim": "3.*"
  }
}

Um diese Abhängigkeiten initial dem Projekt hinzuzufügen, muss der Befehl:

composer install

eingegeben werden. Anschließend werden die Abhängigkeiten aufgelöst und heruntergeladen:

Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 6 installs, 0 updates, 0 removals
  - Installing psr/container (1.0.0): Loading from cache
  - Installing container-interop/container-interop (1.2.0): Loading from cache
  - Installing nikic/fast-route (v1.3.0): Loading from cache
  - Installing psr/http-message (1.0.1): Loading from cache
  - Installing pimple/pimple (v3.2.3): Loading from cache
  - Installing slim/slim (3.12.1): Loading from cache
Writing lock file
Generating autoload files

Nach der initialen Installation, finden die sich die Abhängigkeiten im Ordner vendor. Daneben wird eine composer.lock-Datei angelegt. In dieser sind die genauen Versionsnummern, der installierten Abhängigkeiten hinterlegt. Würde das Projekt nun nochmal mit der install-Option aufgerufen werden, so würden exakt diese Versionen installiert. Sollen diese Abhängigkeiten später aktualisiert werden, kann dafür der Befehl:

composer update

genutzt werden. Dabei werden die Versionen, welche sich in der composer-lock-Datei befinden ebenfalls aktualisiert.

getcomposer.org

Bezogen werden kann Composer unter anderem auf der offiziellen Seite unter getcomposer.org. Der Quelltext von Composer ist auf GitHub zu finden. Die Software ist unter der MIT-Lizenz lizenziert und damit freie Software.

Rewrites unter Nginx loggen

In der Konfiguration für den Webserver Nginx bzw. dessen Seiten, ist es möglich Rewrite-Direktiven zu nutzen. Damit können URLs umgeschrieben werden. Ein Beispiel für eine solche Direktive wäre z.B.

try_files $uri $uri/ @rewrite;

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

Wenn dieser Rewrite zur Anwendung kommt, erscheint leider keine Meldung in den Nginx-Logs access.log und error.log. Um das Logging für Rewrites zu aktivieren, muss die Option:

rewrite_log on;

im server-Block der Konfiguration, welche unter /etc/nginx/sites-available/ zu finden ist, aktiviert werden. Daneben muss die Logging-Severity, also die Schwere der Events die geloggt werden sollen, angepasst werden. Dazu wird folgende Option dem server-Block hinzugefügt:

error_log /var/log/nginx/error.log notice;

Wenn die Log-Datei nun angeschaut wird, so finden sich dort für jeden Rewrite entsprechende Meldungen:

2019/05/29 08:35:30 [notice] 16054#16054: *127817 „^/(.*)$“ matches „/name/german“, client: 82.193.248.37, server: api.example.com, request: „GET /name/german HTTP/1.1“, host: „api.example.com“
2019/05/29 08:35:30 [notice] 16054#16054: *127817 rewritten data: „/index.php“, args: „_url=/name/german“, client: 82.193.248.37, server: api.example.com, request: „GET /name/german HTTP/1.1“, host: „api.example.com“

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.