Sicuramente una condizione ottimale per ottenere prestazioni migliori della propria web app o del proprio sito web è impostare il cosidetto Far Future Expire Header degli elementi prensenti nelle pagine e delle pagine stesse.

In questo post cercherò di descrivere alcune tecniche per impostare tale condizione.

Cito dal sito di YSlow:

Web page designs are getting richer and richer, which means more scripts, stylesheets, images, and Flash in the page. A first-time visitor to your page may have to make several HTTP requests, but by using the Expires header you make those components cacheable. This avoids unnecessary HTTP requests on subsequent page views. Expires headers are most often used with images, but they should be used on all components including scripts, stylesheets, and Flash components.

Quindi in pratica che fa?:-)

L’Expire Header definisce la scadenza dell’oggetto che il browser preleva dal server e deposita nella cache del client. Impostando la “data di scadenza” ad un periodo molto lontano (Far Future per l’appunto) diciamo al browser di non richiamare più tale componente durante le succesive visite alla pagina che lo conteneva, rendendo di fatto la navigazione più veloce. Inoltre, applicando questa tecnica ad elementi comuni a tutte le pagine (es: background o file javascript o file css) l’utente usufruirà dei benefici di questa tecnica fin dalla seconda pagina che andrà a visualizzare sul nostro sito.

Vediamo come fare.

Tramite l’uso di .htaccess (Apache)

<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf|php|html|htm|php4|php5)$">
Header set Expires "Thu, 2 Feb 2010 20:00:00 GMT"
</FilesMatch>

con l’istruzione FileMatch indichiamo a quale tipo di file applicare le regole all’interno del blocco di codice e con “Header set Expires” andremo a dire ad Apache di servire il contenuto indicato con una data di scadenza molto lontana. Nell’esempio ho usato il 2 Febbraio 2010, alle 8 di sera.

Tramite le impostazioni di IIS 6.0

1. Aprite il pannello di controllo di Internet Information Services (IIS).
2. Espandete “LocalMachine” sul pannelo di sinistra e succesivamente cliccate su Web Sites
3. Click con il tasto destro sul sito interessato e selezionate Properties.
4. Nel tab HTTP Headers, attivate la checkbox “Enable Content Expiration” e succesivamente selezionate l’opzione “Expire On”. e impostare il 2 Febbraio 2010 alle 8 di sera
5. Riavviate tutti i servizi IIS.

Con PHP
File far_future_loader.php

<?php
header("Content-type: text/javascript; charset: UTF-8");
header("Cache-Control: must-revalidate");
header("Expires: " . gmdate("D, d M Y H:i:s",time() + (60 * 60 * 24 * 3)) . " GMT");
include(dirname(__FILE__).'/scripts.js');
?>

con il codice sopra potete, ad esempio, raggruppare tutti i vostri file javascript in un unico grande file .php, modificare l’header Content-type in modo che venga interpretato correttamente dal browser come text/javascript e poi modificarne a piaciemento la deata di scandenza.
Successivamente nell’header delle vostre pagine, anzichè includere i singoli file javascript con l’istruzione:

<script type="text/javascript" src="js/scripts.js"></script>

userete

<script type="text/javascript" src="js/far_future_loader.php"></script>

Potete usare il file far_future_loader.php per ogni tipo di file, semplicemente cambiano il Content-type dei file che andrete ad includere, ad esempio, se volete averne uno anche per i file .css dovrete scrivere:

<?php
header("Content-type: text/css; charset: UTF-8");
header("Cache-Control: must-revalidate");
header("Expires: " . gmdate("D, d M Y H:i:s",time() + (60 * 60 * 24 * 3)) . " GMT");
include(dirname(__FILE__).'/style.css');
?>

e successivamente nell’header delle vostre pagine, esattamente come avete fatto per il file javascript, sostituirete l’istruzione:

<link rel="stylesheet" href="css/style.css" type="text/css" />

con

<link rel="stylesheet" href="css/far_future_loader.php" type="text/css" />

Con ASP
la procedura è identica a quella per PHP con la sola differenza che in ASP gli header si setttano con i seguenti comandi:

<% Response.CacheControl = "must-revalidate" %>
<% Response.Expires = -1 %>

Con JSP (Tomcat)
Grazie a Byron Tymvios su jGuru
E’ possibile ottenere l’identico risultato avuto con PHP o ASP tramite i filtri. Ad esempio:

package com.xyz
 
import java.io.IOException;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletResponse;
 
public class CacheFilter implements javax.servlet.Filter {
  FilterConfig filterConfig = null;
 
  public void init(FilterConfig filterConfig){
    this.filterConfig = filterConfig;
  }
 
  public void doFilter(ServletRequest req,
     ServletResponse res,
     FilterChain chain)
     throws IOException, ServletException {
    String sCache = filterConfig.getInitParameter("cache");
 
    if(sCache != null){       ((HttpServletResponse)res).setHeader("Cache-Control", sCache);
 
    }
 
    chain.doFilter(req, res);
  }
 
  public void destroy(){
    this.filterConfig = null;
  }
}

e poi impostare nel file web.xml il filtro per ogni contenuto desiderato. Ecco l’esempio per i file .jpg:

<filter>
  <filter-name>Cache</filter-name>
  <filter-class>com.xyz.CacheFilter</filter-class>
  <init-param>
    <param-name>cache</param-name>
    <param-value>public, max-age=2592000</param-value>
  </init-param>
</filter>
<filter-mapping>
  <filter-name>Cache</filter-name>
  <url-pattern>*.jpg</url-pattern>
</filter-mapping>

è tutto
nella prossimo post parleremo degli ETag.
Giovanni

Purtoppo a volte è necessario modificare i path di default.
Vediamo come

Innanzitutto loggatevi sulla vostra macchina con privilegi di root

# su -

controlliamo i parametri del nostro suexec:

# /usr/lib/apache2/suexec -V
     -D AP_DOC_ROOT="/var/www"
     -D AP_GID_MIN=100
     -D AP_HTTPD_USER="www-data"
     -D AP_LOG_EXEC="/var/log/apache2/suexec.log"
     -D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
     -D AP_UID_MIN=100
     -D AP_USERDIR_SUFFIX="public_html"

come potete vedere dal risultato, i parametri cablati al momento della compilazione sono molti.
spostiamoci in /usr/src e scarichiamo i sorgenti necessari al nostro scopo

# cd /usr/src
# apt-get update
# apt-get build-dep apache2
# apt-get source apache2

ok, adesso spostiamoci nella directory con i sorgenti e configuriamo apache con i parametri che ci interessano:

# cd apache2-2.2.3
# nano debian/rules

all’interno del file rules troverete un sacco di parametri. quelli ci interessano in questo momento sono quelli sotto la voce AP2_COMMON_CONFARGS.
quindi modifichiamo quanto ci serve andando a cambiare quanto presente alla riga

      --with-suexec-docroot=/home/hosting \

e salviamo.
ora, semplicemente, dovremmo ricompilare il file. prima di farlo però, è necessario modificare la versione di apache in modo tale che il nostro cambiamento non venga sovrascritto ad ogni upgrade.
quindi

# dch -i

e ci troviamo all’interno del changelog di apache.
UN CONSIGLIO: se non volete dover reinstallare tutti i pacchetti di apache, eliminate la versione che dch vi aggiunge in automatico e andate a lavorare sull’ultima. aggiungete un bel * e inserite il vostro commento, tipo: “fixed suexec docroot to: /home” e salvate.
in questo modo la versione rimarrà inalterata e apache installerà solo la “patch” da voi applicata

a questo punto dobbiamo solo compilare e pacchettizzare

# dpkg-buildpackage

aspettate la fine delle operazioni di compilazione, tornate in /usr/src e installate i pacchetti modificati (nel nostro caso apache2.2-common e apache2.2-utils)

# cd /usr/src //o se volete cd ../
# dpkg -i apache2.2-common_2.2.3-4+etch6_amd64.deb 
# dpkg -i apache2-utils_2.2.3-4+etch6_amd64.deb

fatto questo restartate apache, verificate che tutto sia andato a posto ed eventualmente controllate i conflitti con apt

# /etc/init.d/apache2 restart
# /usr/lib/apache2/suexec -V
     -D AP_DOC_ROOT="/home"
     -D AP_GID_MIN=100
     -D AP_HTTPD_USER="www-data"
     -D AP_LOG_EXEC="/var/log/apache2/suexec.log"
     -D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
     -D AP_UID_MIN=100
     -D AP_USERDIR_SUFFIX="public_html" 
# apt-get install -f

alla prossima!

In particolare Internet Explorer 6 mi ha dato una bella gatta da pelare con i file da scaricare.
In un’applicazione web che ho scritto è possibile scaricare alcuni file, solo da parte di utenti registrati. Quindi i file stanno fuori dalla visibilità del browser e vengono serviti da un file (download.php, nel mio caso) che, dopo aver fatto i relativi controlli a login e permessi vari, cambia gli header in modo da far scaricare il file scelto. Semplificando molto è una cosa simile:

1
2
3
4
5
6
7
8
9
10
11

<?php
session_start();
$db = new db();
checkPermission($_GET['id'],$_SESSION['userid']) || die();
$file = $db->query("SELECT * FROM attachments WHERE id = ".$db->quote($_GET['id']);
header ("Content-type: ".$file['mime']);
header ("Content-disposition: attachment; filename=".$file['name']);
header ("Content-Transfer-Enconding: binary");
@readfile($file['full_path']);
exit();
?>

Risultato? Con Firefox nessun problema, con IE 7 nessun problema (eh meno male!!) ma con IE6… disastro!! I file venivano scaricato, ma IE6 ignorava bellamente l’header content-type e l’header content-disposition, nominando il file “download.php”.

Le ho provate davvero tutte per ovviare a questo problema, cambiare header rigurdanti la cache,ecc. ecc., ma l’unico effetto che sono riuscito ad ottenere è stato che il file non si chiamava più download.php, ma download.pdf piuttosto che download.zip…ma io voglio il nome corretto!!!

Google alla mano, ho fatto mille ricerche che non hanno portato a nulla finchè non sono arrivato a questa pagina: http://www.sitefoundry.com/broken_msie.html
e qui ho appreso che per un baco, IE6 in questi casi tenta sempre due richieste andando in errore e che a differenza di Firefox utilizza il protocollo HTTP 1.1 anziché 1.0. Allora mi sono detto: “non è che è tutto un problema di protocollo?!?”.
Prima di:

1

header ("Content-type ...");

ho inserito la seguente riga:

1

header ("HTTP/1.0 200 OK");

forzando così che la mia risposta sia in HTTP/1.0…e ha funzionato!!!
La mia spiegazione è questa: IE cerca (per motivi di sicurezza, dicono) di indentificare autonomamente il tipo di file, ignorando i Content-type e content-disposition vari che si mettono. Forzando il protocollo HTTP a 1.0 probabilmente IE si va a trovare in una modalità compatibile col vecchio protocollo, disabilitando le feature che normalmente utilizza col protocollo HTTP/1.1.

Bisogna stare attenti però all’output compression: il vostro server (Apache) potrebbe avere attivo mod_gzip, il che porterebbe a “g-zippare” tutto il suo output per risparmiare banda di rete. Purtroppo il “caro vecchio” IE6 ha un po’ di problemi a trattare gli header con output gzipped.
La soluzione è in questo caso aggiungere una riga

1

apache_setenv("no-gzip","1");

al vostro script, prima di mandare in output il file da servire. Eventualmente verificate anche che sia disattivata la compressione gzip da PHP.
Per disattivarla occorre aggiungere

1

ini_set("zlib.output_compression","Off");

Io ci sono impazzito 2 giorni su sta cosa…spero che possa essere d’aiuto a molti!