Categories
System Administration

Check HTTP with telnet

HTTPS may become the standard quickly, but HTTP is still the base, and understanding how to verify an HTTP server without a web browser can be very useful. A lot of situations simply don’t allow you to install a web browser or gives only a blank page.

As HTTP is a plain-text protocol you can simulate a connection with telnet on the command line. So let connect to a fresh Linux machine with Apache running and see what happens. After connecting you type in “GET /index.html HTTP/1.1” to tell web server which files you want to get and in this case the file in /index.html. The second line tells the web server for which website you make the request which is 192.168.121.7.xip.io in the example. And finally, you give an additional entry to tell your request is complete and can be processed after which you get the response.

$ telnet 192.168.121.7.xip.io 80
Trying 192.168.121.7...
Connected to 192.168.121.7.
Escape character is '^]'.
GET /index.html HTTP/1.1
Host: 192.168.121.7.xip.io

HTTP/1.1 404 Not Found
Date: Sun, 06 Jan 2019 01:27:00 GMT
Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/7.3.0
Content-Length: 208
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /index.html was not found on this server.</p>
</body></html>
Connection closed by foreign host.

The response in the example tells that the file index.html doesn’t exist on the web server, which is correct for this example. It also gives additional metadata about the server and the form the content is served which can be handy to see if the mime-type matches or the response size is correct.

Categories
Internet, Unix en security

HTTPS forceren

Er is veel te doen over HTTP versus HTTPS en met de “gratis” SSL-offloaders in de systemen van Sun Microsystems met de UltraSPARC T1, T2 en T2+ processor wordt het interessant om af te stappen van HTTP. Gelukkig hebben oa Intel-processoren optimalisatie voor oa AES en is met de juiste aanpassing aan het besturingssysteem en middleware zoals Apache mogelijk om SSL-verkeer sneller te laten afhandelen.

Nu kan je in de webapplicatie inbouwen dat dit moet gebeuren, maar als je massaal HTTP-verkeer naar HTTPS wilt migreren is het verstandiger om dit af te dwingen in de webserver. Zo ook voor een webmail-applicatie in dit geval waarbij de configuratie fouten kan opleveren en programmeurs snel fouten kunnen maken.

Door de volgende regels in de .htaccess-file te zetten in de documentroot van de website zal Apache tegen de webbrowser vertellen dat dit moet worden aangeleverd via HTTPS. Elke webbrowser die de HTTP statuscodes begrijpt zal dit vlekkeloos uitvoeren.

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

Aan deze oplossing zit wel een performance penalty verbonden. De initiale opbouw naar de website kan iets langer duren door de redirect naar de HTTPS-site, maar de grootste penalty zal zitten in de .htaccess-file. Bij productie websites is het dan ook verstandig om dit op te nemen in de virtual host configuratie binnen Apache zelf en de ondersteuning voor .htaccess-files uit te zetten. Hierdoor hoeft we webserver minder de documentroot voor de website af te zoeken naar oa de .htaccess-file.

Categories
Internet, Unix en security

Wat, waar en hoelang dingen te cachen

Door te cachen kan veel worden versnelt, maar tot welke prijs? Elke applicatie lijkt tegenwoordig zijn eigen cache-oplossing te hebben voor bv favicons, data binnen gehaald via HTTP, avatars, icons, maar ook sessies. En dit is natuurlijk allemaal leuk en aardig, maar als je regelmatig een backup wilt maken dan begint dit langzaam een probleem te worden. Een kleine scan in mijn homedirectory levert al z’n 1,6GB aan data op wat te bestempelen is als vluchtig.

$ du -sk .thumbnails .cache .gnome2/epiphany/favicon_cache .liferea_1.6/cache .evolution/cache .evolution/mail/{imap,nntp} .mozilla/*/*/Cache .nautilus/metafiles .purple/icons .config/gnome-session .config/session-state | sort -nr
983740 .cache
573764 .thumbnails
38088 .evolution/mail/nntp
30296 .evolution/mail/imap
3324 .gnome2/epiphany/favicon_cache
3284 .mozilla/firefox/h18d1d1h.default/Cache
1268 .nautilus/metafiles
428 .purple/icons
368 .evolution/cache
188 .liferea_1.6/cache
108 .config/gnome-session
100 .config/session-state

Nu zal het veel nut hebben, maar heeft het echt zin om thumbnails te bewaren van bestanden die al lang zijn gearchiveerd in /dev/null. En is het zinvol dat verschillende applicaties een eigen cache vullen om zo snel mogelijk een favicon op het scherm te toveren. Gelukkig volgen steeds meer applicaties de guidelines van Freedesktop.org om cache bestanden op te slaan in $HOME/.cache zodat ze makkelijk te excluden zijn voor oa backup en timemachine-achtige applicaties.

De vraag blijft dan eigenlijk over hoe lang een item in een cache moet blijven staan. Als het oorsponkelijk object niet meer bestaat? Als het al 30 dagen niet meer is geraadpleegd? Als de expiretime van bv het originele object is verlopen? Of laten we dit afhangen van de hoeveelheid vrije schrijfruimte of van de ondegelegen storage zoals een harddisk vs solid state disk. Een andere beslissing kan zijn dan lokaal cachen goedkoper is dan van ver ophalen. Bij dit laatste vraag ik me af of een HTTP HEAD-request echt veel extra kost.