Una delle situazioni più comuni che rientrano in questo caso è rappresentata dalle pagine oggetto di campagne online. Il canonical link è un compromesso molto recente e supportato solo da un ristretto numero di motori di ricerca. Nell’incertezza, qualcuno preferisce ancora ricorrere al buon vecchio metodo dell’URL rewrite e del redirect.

Questa mattina mi ha citofonato Francesco, intento a risolvere proprio questa situazione. Tutto nasce dal problema che non è possibile utilizzare mod_alias per impostare un redirect basato su un parametro in querystring. Per approfondimenti vi rimando all’articolo Apache .htaccess query string redirects.

Per la gioia di chi non ama gli indovinelli, ecco la soluzione al problema.

Il codice seguente è una regola di riscrittura di Apache. Può essere inserita direttamente nel file di configurazione del virtual host o all’interno dell’.htaccess. Nel caso la querystring contenga un parametro di Google Analytics per il tracciamento di una campagna, esegue il reindirizzamento alla pagina a se stessa rimuovendo la querystring.

RewriteEngine On
RewriteCond %{QUERY_STRING} utm_source=(.*?)   [OR]
RewriteCond %{QUERY_STRING} utm_medium=(.*?)   [OR]
RewriteCond %{QUERY_STRING} utm_content=(.*?)  [OR]
RewriteCond %{QUERY_STRING} utm_campaign=(.*?)
RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1? [R=301,L]

Se desiderate eseguire la riscrittura forzata per una pagina specifica o un gruppo di pagine, è sufficiente aggiungere una condizione sulla pagina richiesta. L’esempio seguente applica il redirect solo nel caso in cui i parametri si trovino sulla query string della homepage.

RewriteEngine On
RewriteCond %{REQUEST_URI}  ^/$
RewriteCond %{QUERY_STRING} utm_source=(.*?)   [OR]
RewriteCond %{QUERY_STRING} utm_medium=(.*?)   [OR]
RewriteCond %{QUERY_STRING} utm_content=(.*?)  [OR]
RewriteCond %{QUERY_STRING} utm_campaign=(.*?)
RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1? [R=301,L]

Altre soluzioni o suggerimenti sono ben accetti. Segretamente, Francesco mi ha confessato che alla soluzione migliore regalerà un viaggio premio in Brasile per assistere al Carnevale di Rio.

Related posts:

1. Proposta: reindirizzare un feed senza HTTP 301
2. Google Analytics: nell’head o nel body?
3. Invito Google Analytics: li invia solo Google!

Prendete questo articolo come una sorta di cheatsheet, una raccolta di esempi per restituire http status code con Apache e .htaccess. L’articolo non è cortissimo, ho deciso di dividerlo in 4 pagine. Il link per la navigazione delle pagine è disponibile al fondo di ogni pagina, prima dei commenti.

Requisiti e Premesse

Poiché il focus di questo articolo è squisitamente tecnico, partirò dal presupposto che conosciate almeno le basi del funzionamento di Apache e le caratteristiche essenziali del file .htaccess.
Inoltre, non mi soffermerò a dettagliare il significato di ogni status code, delegando invece alla documentazione ufficiale eventuali approfondimenti.

Classificazione degli status code HTTP

Gli HTTP Status code sono normalmente classificati per tipo di risposta e si suddividono in:

1. Informational
2. Successful
3. Redirection
4. Client Error
5. Server Error

Il quarto e quinto insieme possono essere identificati in un colpo solo come Error Responses. Ecco lo schema riassuntivo, presente nella definizione del file sorgente di Apache che indica anche, per ogni classe di status code, il suo range di valori.

/** is the status code informational */
#define ap_is_HTTP_INFO(x)     (((x) >= 100)&&((x) < 200))
/** is the status code OK ?*/
#define ap_is_HTTP_SUCCESS(x)    (((x) >= 200)&&((x) < 300))
/** is the status code a redirect */
#define ap_is_HTTP_REDIRECT(x)   (((x) >= 300)&&((x) < 400))
/** is the status code a error (client or server) */
#define ap_is_HTTP_ERROR(x)    (((x) >= 400)&&((x) < 600))
/** is the status code a client error  */
#define ap_is_HTTP_CLIENT_ERROR(x) (((x) >= 400)&&((x) < 500))
/** is the status code a server error  */
#define ap_is_HTTP_SERVER_ERROR(x) (((x) >= 500)&&((x) < 600))
/** is the status code a (potentially) valid response code?  */
#define ap_is_HTTP_VALID_RESPONSE(x) (((x) >= 100)&&((x) < 600))

Al fine del nostro articolo gli insiemi di status code più interessanti sono i redirect e gli errori. Gli altri casi denotano richieste processate secondo il normale flusso previsto dal web server e difficilmente ci troveremo ad impostare a mano uno di questi valori.

HTTP Redirect

Come anticipato in apertura, non mi dilungherò troppo per quanto riguarda gli status code di reindirizzamento. I due più importanti sono l’HTTP 301 e l’HTTP 302. Entrambi possono essere impostati utilizzando sia il mod_alias, sia il cugino mod_rewrite.

Redirect con mod_alias

Nel primo caso è sufficiente indicare il tipo di redirect dopo al comando di reindirizzamento, come segue.

Redirect temp /old http://site.com/new
Redirect permanent /old http://site.com/new

Entrambe le direttive accettano anche il rispettivo status code.

Redirect 302 /old http://site.com/new
Redirect 301 /old http://site.com/new

Nel caso in cui né lo status code né la sua descrizione sia presente, Apache imposta il tipo di redirect a 302.

Altrettanto interessante, mod_alias supporta anche lo status di reindirizzamento seeother, rappresentato dal valore 303.

Redirect 303 /old http://site.com/new
Redirect seeother /old http://site.com/new

Tutte le direttive sopra descritte sono ugualmente supportate dal comando RedirectMatch.

Redirect 301        /old/(.*) http://site.com/new/$1
Redirect permanent  /old/(.*) http://site.com/new/$1
Redirect 302        /old/(.*) http://site.com/new/$1
Redirect temp       /old/(.*) http://site.com/new/$1
Redirect 303        /old/(.*) http://site.com/new/$1
Redirect seeother   /old/(.*) http://site.com/new/$1

mod_alias mette anche a disposizione alcune scorciatoie per i due tipi di redirect più diffusi.

  Redirect 301      /old http://site.com/new
  RedirectPermanent /old http://site.com/new

  Redirect 302      /old http://site.com/new
  RedirectTemp      /old http://site.com/new

Redirect con mod_rewrite

La sintassi per eseguire un redirect con mod_rewrite è altrettanto semplice. E’ sufficiente scrivere una regola di rewrite ed appendere al fondo il flag [R=XXX] sostituendo XXX con lo status code desiderato.

RewriteRule       /old http://site.com/new
RewriteRule       /old http://site.com/new
RewriteRule       /old/(.*) http://site.com/new/$1 [R=301]
RewriteRule       /old/(.*) http://site.com/new/$1 [R=302]

A differenza di mod_alias, se il flag è omesso la richiesta viene riscritta e non reindirizzata.

HTTP Client Error

L’insieme dei client error, identificato dal range >= 400 && < 500, è probabilmente quello con maggiori applicazioni pratiche ed anche il più interessante.

HTTP 404

Cominciamo con il più diffuso dei codici di errore, l’HTTP 404. Il modo più efficace per restituirlo… è cancellare il contenuto dell’indirizzo. E’ difficile che vi troviate a dover restituire un errore HTTP 404 via Apache, ma se questo fosse il vostro caso allora una soluzione è creare una pagina dinamica, ad esempio in PHP, e riscrivere l’indirizzo per puntare a quella pagina.

Ecco il contenuto del file 404.php:

<?php
header("HTTP/1.0 404 Not Found");

Ed ecco come riscrivere la pagina old.php affinché ritorni un errore 404.

RewriteRule ^old\.php$ 404.php [L]

HTTP 401

Anche per impostare un errore HTTP 401 possiamo affidarci al modulo mod_rewrite ed a una pagina personalizzata, proprio come descritto per l’errore HTTP 404.

E’ anche possibile impostare una basic auth per il percorso che intendiamo proteggere. In caso l’utente non fornisca le credenziali corrette, Apache restituirà in automatico un errore 401.

HTTP 403

Come per i precedenti, anche per l’HTTP 403 utilizziamo mod_rewrite ma questa volta Apache ci mette a disposizione lo speciale flag [F].

RewriteRule ^folder/(.*)$ - [F,L]

Il primo parametro contiene il path da proteggere, il secondo è invece un semplice trattino -. Si utilizza quando non si desidera riscrivere path ma solo sfruttare RewriteRule per appendere dei flag alla request.

L’alternativa è utilizzare le direttive di raggruppamento Files, FilesMatch, Directory, DirectoryMatch e Location per modificare le impostazioni di accesso attraverso i comandi Order e Deny. L’esempio seguente dimostra come restituire un errore 403 quando l’utente tenta di accedere ad una cartella speciale di SVN.

<DirectoryMatch "^/.*/\.svn/">
  Order allow,deny
  Deny from all
  Satisfy All
</DirectoryMatch>

HTTP 410

L’ultimo status della categoria client error che vale la pena considerare è lo status HTTP 410. All’argomento ho dedicato un post speciale qualche giorno fa, intitolato Serve a qualcosa lo status HTTP 410?.

Anche in questo caso, possiamo procedere sia con mod_alias, sia con mod_rewrite.
Ad esempio, ecco come possiamo indicare che il feed atom.xml del nostro blog non è più disponibile.

# le seguenti righe sono equivalenti nel risultato
Redirect 410  /blog/atom.xml
Redirect gone /blog/atom.xml
RewriteRule   ^blog/atom.xml$ - [G,L]

Server Error

Perché mai dovremmo voler restituire uno status code che identifica un errore del server? Non bastano da soli i famosi errori 500 causati di norma dai bug senza che ci mettiamo del nostro per restituire questo genere di errori?

Un’esempio eccellente è possibile ritrovarlo in un post di Maurizio, con tanto di conferma ufficiale da parte di Google. In breve, se state eseguendo operazioni di manutenzione sul server può essere utile restituire temporaneamente un errore 503.

Proprio da questo caso vorrei partire con due esempi. Il primo, ripreso direttamente dal blog di Maurizio, dimostra come è possibile utilizzare la strategia prima descritta per 404 e 401 per ottenere uno status code 503 per qualsiasi pagina del sito.

RewriteCond %{REQUEST_URI} !^/errors/503/index\.php [NC]
RewriteRule .* /503.php

<?php
header('HTTP/1.1 503 Service Temporarily Unavailable');
header('Retry-After: 3600');

Il secondo esempio è invece un estratto da una regola installata sui nostri server di produzione necessaria al funzionamento di Capistrano per Ruby on Rails. In questo caso, la sintassi è più complessa ma dimostra come ottenere lo stesso risultato con il solo uso di Apache senza eventuali file php esterni.

# Maintenance Page
# Handle the HTTP 503 status code with a special page
# and send Retry-After header in case of maintenance.
ErrorDocument 503 /errors/503.html

<LocationMatch "/errors/503\.html">
  Header set Retry-After "3600"
</LocationMatch>  

# for the maintenance time
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !503\.html
RewriteRule ^.*$ /errors/503.html [R=503,L]

In conclusione

Conoscere ed utilizzare gli HTTP status code nel modo corretto è un requisito imprescindibile per chi lavora a stretto contatto con pagine web, web server ma soprattutto client come i motori di ricerca.
Se fino ad oggi non avevato ancora approfondito l’argomento, questa è la volta buona per sgranocchiare un po’ di documentazione.

Questo articolo dovrebbe darvi le indicazioni necessarie per gestire attraverso Apache e .htaccess i principali HTTP status code.
Per verificare il risultato dei vostri esperimenti potete usare l’HTTP Status Code checker disponibile su questo sito.

Related posts:

1. Importanti aggiornamenti al tool HTTP Headers Status Checker
2. Serve a qualcosa lo status HTTP 410?
3. Guida per impostare un redirect 301

Che cos’è lo status HTTP 410?

Come ben saprà chi legge abitualmente questo blog o si interessa di server, un server può restituire diversi status code in risposta ad una richiesta di una pagina web. Tra gli status code pià famosi troviamo

• HTTP 200 in caso di risposta completata con successo
• HTTP 404 in caso di risorsa non trovata
• HTTP 403 in caso di accesso non consentito

Lo status code restituito da un server è fondamentale e determina il risultato di una risposta HTTP. Parlando di motori di ricerca, lo status code influenza il posizionamento di una pagina così come la sua indicizzazione.

Lo status code 410 rappresenta la risposta in caso di risorsa non più disponibile. La sua definizione tecnica è HTTP 410 Gone. Per certi versi è molto simile al 404 poiché entrambi identificano una risorsa irraggiungibile, tuttavia esiste una differenza non banale:

• lo status code 404 indica una risorsa non disponibile.
• lo status code 410 indica una risorsa non più disponibile.

In altre parole, lo status code 410 implica che a quell’indirizzo prima fosse disponibile una risorsa che, al momento, è stata rimossa. Al contrario, lo status code 404 non fornisce questo dettaglio: l’indirizzo richiesto forse non ha mai ospitato una risorsa, forse sì… non si sa.

Agli occhi della maggior parte dei client ciò che conta è il risultato. In entrambi i casi ci troviamo di fronte ad una risorsa non disponibile e l’errore va gestito. Alcuni software rimuovono la risorsa dai propri indici, altri la nascondono, altri ancora mettono in atto azioni correttive per verificare un’eventuale collocazione alternativa.

La maggior parte dei motori di ricerca afferma di gestire lo status code 410 allo stesso modo del 404. Obiettivo del mio test era verificare quest’affermazione sfruttando la necessità di voler rimuovere un feed non più disponibile.

Numero di richieste HTTP

Il grafico seguente riassume le richieste HTTP inviate alla pagina /atom.xml prima e dopo l’impostazione dello status code HTTP 410, il 5 Ottobre 2008.

Nota. Per ingrandire i valori potete con il mouse selezionare una porzione del grafico. Lo script provvederà ad ingrandire a schermo solo il range che avete evidenziato.

I risultati

Analizzando i risultati dell’esperimento è possibile osservare diversi comportamenti curiosi. Ecco alcune mie considerazioni, in ordine sparso.

1. Contrariamente ad ogni mia aspettativa, lo status HTTP 410 è supportato da una buona fetta dei client web: crawler, motori di ricerca, parser… E’ possibile notare come, nel giro di qualche giorno, le richieste alla pagina sono diminuite sensibilmente.
2. A differenza dello status HTTP 404, lo status HTTP 410 ha un effetto quasi immediato. Teoricamente parlando questo ha un senso ma, anche in questo caso, non mi sarei aspettato una così concreta aderenza alle specifiche. Il motivo per il quale l’HTTP 410 è così immediato è da ricercare nel suo significato: la volontà di azione. A differenza del 404 che potrebbe essere casuale o involontario, l’HTTP 410 non è uno status code predefinito e viene impostato deliberatamente. Questa sottile differenza autorizza il client ad agire senza eccessivi controlli aggiuntivi, come avviene invece nel caso di un HTTP 404.
3. A differenza dello status HTTP 404, buona parte dei client mette in atto un processo di rimozione irreversibile. In altre parole, una volta appurata la non disponibilità della risorsa, i client limitano i controlli periodici ad una frequenza inferiore a quella normalmente prevista per un HTTP 404.

In conclusione, direi che è possibile affermare con una discreta certezza che l’HTTP 410 è efficace. Inoltre, sembra essere dimostrato che per rimuovere velocemente una pagina dalla rete questo status code rappresenta una soluzione più efficace rispetto alla semplice cancellazione del file dal server e conseguente HTTP 404.

Related posts:

1. Come restituire HTTP Status Code specifici con Apache e .htaccess
2. Importanti aggiornamenti al tool HTTP Headers Status Checker
3. Strumenti SEO: HTTP Headers Status Checker

Era dal tempo del post Quanti dati indicizza Google?, quindi oltre un anno fa, che non mi capitava di sgranocchiare altrettanto impazientemente un whitepaper su un’architettura degna di interesse.
Grazie ad un vecchio post di Kevin Burton scopro che Domas Mituzas, che lavora per MySQL AB e Wikipedia, ha pubblicato un interessante workbook sull’architettura interna dei server della famosa enciclopedia. Sempre dal post di Domas scopro che un altro interessante whitepaper pubblicato illustra l’architettura di WikiMedia.

Per i più curiosi che non disdegnano qualche pillola ma che non amano dedicarsi alla lettura di questi documenti, ecco alcune informazioni.

Architettura LAMP

Wikipedia si basa su una architettura LAMP, ovvero

• Sistema operativo Linux, normalmente Fedora o Ubuntu
• WebServer Apache
• Database MySQL
• Linguaggio di programmazione PHP, versione 5 (requisito minimo della piattaforma MediaWiki)

La piattaforma è MediaWiki, progettata e sviluppata dalla WikiMedia Foundation che, per intenderci, è la stessa fondazione alla base di WikiPedia.
Per accelerare i tempi di caricamento e gestire al meglio il carico, subentrano alcuni componenti di caching e distribuzione come

• Il proxy SQUID
• Il webserver lighttpd per la gestione dei file statici
• Memcached per il caching di alcune risorse ed elaborazioni

Il documento prosegue poi presentando nel dettaglio l’architettura del sistema di caching e del database, fornendo utili informazioni su come ottimizzare ad esempio le query con appositi indici.
Il sistema di ricerca si basa su un porting di Lucene (che nativamente è scritto in Java) mentre il bilanciamento del carico è affidato a LVS (Linux Virtual Service).

Il whitepaper conta 30 pagine di dettagli tecnici ed utili informazioni, soprattutto per chi si prepara alla creazione di un progetto che dovrà presumibilmente sostenere carichi non indifferenti. Un’ottima lettura, non certo da ombrellone però.

Related posts:

1. Wikipedia rimuove l’attributo nofollow

MyIPNeighbors.com potrebbe fare al caso tuo.
Un veloce e semplice tool per individuare, via reverse IP, la lista dei domini configurati su un server indicato.

Related posts:

1. Google Web Server (GWS) esiste!
2. Leggendo i log ho scoperto… #9 – Errori nella configurazione server
3. 113 server per gestire Google Calendar

Così, analizzando un po’ di header ho scoperto una cosa singolare che non avevo ancora notato.
Tra i suoi header, alla voce Server Google restituisce GWS/2.1, acronimo di Google Web Server versione 2.1.

Insomma, al di là delle tanto chiacchierate voci su Google FileSystem, Google Office e via dicendo, il Google Web Server esiste ed è quello che ogni giorno fornisce pubblicamente il risultato delle query agli utenti.
Qualche timida informazione è disponibile su Wikipedia inglese, ma nulla più di una citazione.

Analizzando un po’ di risorse in rete sembrerebbe che il Sistema Operativo che gestisce tali server sia una versione modificata di Linux Red Hat.
Il web server base è Apache, anch’esso modificato e denominato Google Web Server.
Il motivo principale di queste modifiche, facile identificabile, è quello di avere un’architettura scalare che permetta di distribuire al meglio i carichi, garantire un’elevata potenza di calcolo, bassi costi ma soprattutto una configurazione realmente adatta alle esigenze.

Related posts:

1. 113 server per gestire Google Calendar
2. Yahoo-Blogs: esiste o non esiste?
3. MyIPNeighbors.com individua i siti hostati sullo stesso server

IIS 7.0 uses a new XML-based configuration store that is modeled after the ASP.NET configuration. IIS configuration is stored in the ApplicationHost.config file and can also be distributed among Web.config files for sites, applications, and directories. Settings configured at one level are inherited automatically by lower levels, unless they have been locked to prevent changes. By default, the server administrator is the only user who has permission to view and edit the ApplicationHost.config file.

IIS 7.0 Beta: IIS 7.0 Configuration Store

Quasi sicuramente IIS 7, disponibile a partire da Windows Vista, disporrà di un file di configurazione espandibile fino a livello web, così come avviene al momento per il file .htaccess su Apache.

Finalmente!

Related posts:

1. Leggendo i log ho scoperto… #9 – Errori nella configurazione server
2. Microsoft Outlook ed i file .PST
3. I file PST di Outlook non supportano il salvataggio in cartelle di rete

Fortunatamente, dopo diverse ore passate a litigare con Windows 2003 server via VNC, a postare su vari forum e a dialogare con l’assistenza di Movable Type (in seguito all’acquisto di una licenza completa), sono riuscito ad installare e configurare con successo la piattaforma.
Ad essere sinceri… ne è valsa la pena!

Siccome non ero il primo e non sarò l’ultimo ad incontrare questi problemi, ecco alcuni suggerimenti.

Quale server?

Se dovete installare MT scegliete un server Unix, vi eviterete molti problemi.
Se invece dovete installarlo su un server Windows e potete scegliere tra 2000 e 2003, precipitatevi sul primo. Microsoft Windows 2003 server è indubbiamente migliore rispetto alla versione 2000, ma ha qualche problema in più a digerire MT.

Se qualcuno si stesse chiedendo su quale SO l’ho installato… tutti e tre! ;)

Errori comuni per Windows 2003 server

CGI Error – The specified CGI application misbehaved by not returning a complete set of HTTP headers.

Questo erroraccio è riuscito a farmi impazzire per oltre 3 giorni.
Il motivo alla base è la gestione dei percorsi delle librerie da parte di PERL montato su Win2k3. La situazione in sé anomala è che, per la legge di Murphy, il file mt-check.cgi vi dirà che il sistema è configurato correttamente ed è pronto per l’installazione.

Per risolvere questo errore avete due possibilità, oltre a distruggere il server o cambiare piattaforma.
In ordine di convenienza.

1. Utilizzate la libreria perliis.dll al posto del file perl.exe come interprete del linguaggio PERL.
   Per modificare le impostazioni aprite la console di IIS, pulsante destro del mouse sul nome del web da modificare e scegliete Proprietà.
   A questo punto nella tab Home Directory selezionate il pulsante Configuration (o configurazione) per accedere al mapping delle estensioni.
   Cercate l’estensione .cgi e al posto del percorso predefinito (in genere C:\Perl\bin\perl.exe "%s" %s) selezionate la libreria perlis.dll.
2. Cambiate il percorso della variabile di libreria da lib in PERCORSO_ASSOLUTO\lib.
   Personalmente ho provato anche questa soluzione, ma la sconsiglio.
   Alcuni riferimenti interessanti: http://www.movabletype.org/support/index.php?s=&act=ST&f=7&t=53968&st=0 e http://www.movabletype.org/support/index.php?act=ST&f=7&t=54171&hl=&s=
3. CGI Error on IIS 6.0 (Windows 2003), articolo ufficiale tratto dalla Knowledge Base di SixApart.

‘D:\Inetpub\[...]\mt.cgi’ script produced no output

Questo invece è un altro bell’errore comparso, all’improvviso, dopo qualche giorno di utilizzo di Movable Type, sempre su server Windows 2003.
L’errore compariva solo ed esclusivamente quando tentavo di accedere alla pagina di modifica delle impostazioni di pubblicazione del blog, attraverso il menu Settings > Publishing.

In questa occasione l’assistenza di MT è stata rapida ed eccellente e mi ha consigliato una procedura miracolosa per correggere il problema.

1) Open the tmpl/cms/cfg_archives.tmpl file in a plain text editor (either the copy from your server or from the original download package). Save a backup copy of the file.

2) Look for the following section of code (at about line 246):

<MT_TRANS phrase="This advanced feature allows you to map any archive template to multiple archive types. For example, you may want to create two different views of your monthly archives: one in which the entries for a particular month are presented as a list, and the other representing the entries in a calendar view of that month.">

3) Remove the second sentence of text, so that the code ends up like this:

<MT_TRANS phrase="This advanced feature allows you to map any archive template to multiple archive types.">

4) Save the file and upload it back to the server in ASCII mode, replacing the copy on the server.

Spero che queste piccole pillole possano rendere l’installazione di Movable Type su Microsoft Windows 2003 server più piacevole.

Related posts:

1. Movable Type Hack: da Keywords a Tag
2. Movable Type Plugin: editor di post potenziato con MT Quicktags
3. In previsione un File Manager per Movable Type