Leggendo questo post di Andrea mi è venuto in mente un piccolo addendum al suo esempio, utilizzabile in un caso ben delimitato.
Di default quando ASP.NET va in errore 404 (risorsa non trovata) non invia al browser il codice HTTP corrispondente. La stessa cosa in realtà (non) la fa anche Classic ASP. Se mettete su un sistema che cerca broken link analizzando il codice di risposta del web server, con una pagina personalizzata semplicemente non funzionerà.
E' un'operazione che infatti è demandata allo sviluppatore, anche perchè non è detto che se una risorsa non esiste fisicamente su disco o virtualmente tramite mapping il risultato sia un 404, come in questo esempio, per aggiustare automaticamente l'indirizzo, o questo vecchio url che rimanda in automatico a questo per evitare broken link.
E quindi il succo del discorso è che comunicare all'user agent che visita la pagina (che può non essere un browser) che la risorsa in realtà non esiste più, si può inserire nell'HttpModule utilizzato per l'errore (o nel global.asax o nella pagina di personalizzazione) questo semplice codice:
Response.StatusCode = 404;
Lo so che essere compatibili con il mondo (e con gli standard) richiede sacrificio, ma essere buoni cittadini del web vuol dire anche onorare a dovere i protocolli e gli standard esistenti ;)
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
- ASP.NET 5 e ASP.NET MVC 6: le cose da sapere, il 27 febbraio 2015 alle 09:10
- .NET Framework 4.6, .NET Core 5, ASP.NET 4.6 e ASP.NET 5: un po' di chiarezza, il 13 novembre 2014 alle 10:55
- La lunga strada verso la prossima versione di ASP.NET, il 29 settembre 2014 alle 17:24
- Visual Studio 11 beta: le novità di ASP.NET 4.5, l'1 marzo 2012 alle 19:53
- Inside ModelVirtualCasting #10: tutti pazzi per il web mobile, il 5 luglio 2010 alle 18:47
- Inside ModelVirtualCasting #9: Cache con Windows Server AppFabric, il 2 luglio 2010 alle 12:05