ASP.NET 2.0

[ASP.NET] PageAsyncTask e pagine asincrone

Dario Santarelli — Sat, 08 Nov 2008 15:23:00 GMT

A partire da ASP.NET 2.0, la classe System.Web.UI.Page introduce un metodo non molto conosciuto in grado di facilitare la realizzazione di pagine asincrone: il metodo RegisterAsyncTask. Spesso mi è capitato di vedere implementare chiamate asincrone (es. invocazione di un WebService) in maniera non corretta sfruttando la logica dell' AddOnPreRenderCompleteAsync, quando in realtà molti dei problemi potevano essere gestiti facilmente tramite Task asincroni, che in ASP.NET sono rappresentati dalla classe PageAsyncTask.
Le differenze tra i due approcci non sono moltissime ma significative. Infatti, entrambi richiedono Async="true" nella direttiva @Page (o AsyncMode = true; da codice) e dunque la predisposizione all'esecuzione asincrona della pagina su thread diversi dopo il completamento del PreRender.
Tuttavia, il metodo RegisterAsyncTask introduce i seguenti vantaggi chiave:

In aggiunta ai metodi Begin/End, permette di registrare un metodo per gestire il timeout di una operazione eventualmente troppo lunga. Il timeout è per-page ed è impostabile tramite l'attributo AsyncTimeout della direttiva @Page: <%@ Page Async="true" AsyncTimeout="10" ... %>
Permette di gestire più PageAsyncTask (ovvero più "async points") all'interno di un ciclo di vita di una pagina asincrona. Questi a loro volta possono essere eseguiti sia in modalità sequenziale che in modalità parallela (grazie a questo overload del contruttore di PageAsyncTask). Anche in questo caso, analogamente al pattern MetodAsync/MethodCompleted disponibile per le classi proxy dei WS (dal framework 2.0 in poi), ASP.NET "ritarda" il rendering della pagina finché tutti i task asincroni non sono stati completati.
Permette di passare un oggetto 'state' ai nostri metodi BeginAsync tramite la classe PageAsyncTask.
Permette di mantenere l'impersonation, la culture e l'oggetto HttpContext.Current nei metodi EndAsync e Timeout (cosa non prevista dal metodo EndAsync registrato con l'approccio AddOnPreRenderCompleteAsync)

Mettiamo insieme il tutto e vediamo un esempio di applicazione dei PageAsyncTask.
Vogliamo elaborare dei feed RSS tramite PageAsyncTask diversi all'interno di una nostra pagina asincrona.

public partial class SampleAsyncPage : System.Web.UI.Page
{

protected void Page_Load(object sender, EventArgs e)
{
     List<string> feeds = new List<string>();
     feeds.Add("http://blogs.msdn.com/MainFeed.aspx?Type=AllBlogs");
     feeds.Add("http://blogs.ugidotnet.org/MainFeed.aspx");
     feeds.Add("http://channel9.msdn.com/Feeds/RSS/");

     foreach (string feed in feeds)
     {
       RegisterAsyncTask(new PageAsyncTask(new BeginEventHandler(BeginAsyncOperation), // BeginAsync
                                           new EndEventHandler(EndAsyncOperation), // EndAsync
                                           new EndEventHandler(TimeoutAsyncOperation), // TimeoutAsync
                                           WebRequest.Create(feed), // State
                                           true // I task registrati verranno eseguiti in parallelo
                                          )
                        );
     }
}

IAsyncResult BeginAsyncOperation(object sender, EventArgs e, AsyncCallback callback, object state)
{
    // In rawFeed abbiamo il feed RSS...
    WebRequest webRequest = (WebRequest)state;
    return webRequest.BeginGetResponse(callback, state);
}

void EndAsyncOperation(IAsyncResult ar)
{
    WebRequest webrequest = (WebRequest)ar.AsyncState;
    string rawFeed = null;

    using (WebResponse response = webrequest.EndGetResponse(ar))
    {
      using (StreamReader reader = new StreamReader(response.GetResponseStream())) rawFeed = reader.ReadToEnd();
    }
    // In rawFeed abbiamo il feed RSS...
}

void TimeoutAsyncOperation(IAsyncResult ar)
{
    // Gestione del Timeout per l' AsyncTask
}
}

Per ciascun feed di un nostro elenco registriamo a livello di pagina un PageAsyncTask che in fase di esecuzione si occuperà di reperire lo stream del feed associato (ad esempio grazie alla classe System.Net.WebRequest). Il miglioramento delle prestazioni è garantito anche dal fatto che l'esecuzione asincrona di ciascun Task verrà gestita da ASP.NET possibilmente in parallelo.

Considerazioni:

Se abbiamo bisogno di una pagina asincrona che gestisca un'unica chiamata asincrona, allora gli approcci AddOnPreRenderCompleteAsync e RegisterAsyncTask sono pressoché equivalenti. Ma se le chiamate asincrone sono molte, è decisamente consigliabile sfruttare le facilitazioni introdotte da RegisterAsyncTask.
Il timeout è per-page e non per-call. Non possiamo cioè assegnare timeout diversi a chiamate asincrone diverse!!! Al massimo possiamo eventualmente modificare a runtime la proprietà AsyncTimeout, il che ovviamente non è la stessa cosa :D
In combinazione con async ADO.NET (es. SqlCommand.BeginExecuteReader) ed in generale con le feature asincrone del framework .NET, le pagine ASP.NET asincrone offrono soluzioni molto convenienti per risolvere comuni problemi di I/O legati a scenari che inibiscono la scalabilità.
In generale non è consigliabile/sicuro gestire operazioni asincrone in ASP.NET utilizzando le API System.Threading (es. ThreadPool.QueueUserWorkItem). Il rischio infatti è quello di "rubare" thread alla normale gestione del ThreadPool di ASP.NET, ottenendo effetti che potrebbero risultare addirittura controproducenti.

Technorati Tag: ASP.NET,PageAsyncTask

[ASP.NET] Escludere HttpModule non utilizzati dalla pipeline

Dario Santarelli — Wed, 14 Nov 2007 23:32:53 GMT

Una tip molto utile e non molto conosciuta per cercare di incrementare le performance di una applicazione ASP.NET riguarda la rimozione degli HttpModule non utilizzati, in modo che non vengano caricati e non rispondano ad eventuali eventi applicativi. Poiché la pipeline HTTP viene valutata a partire dal Machine.config, abbiamo a disposizione due modi per ottimizzare il cosiddetto "HTTP pipeline circuit":

Commentare il modulo HTTP che non interessa nel Machine.config (sezione httpModules), scelta in genere non consigliabile dal momento che è applicata a tutte le applicazioni in deploy sulla stessa macchina:
<httpModules>

</httpModules>

Rimuovere esplicitamente i moduli che non interessano nel Web.config di ciascuna applicazione (scelta sicuramente più consigliabile in quanto maggiormente flessibile):
<configuration>
       <system.web>
             <httpModules>
                    <remove name="ModuleName"/>
             </httpModules>
       </system.web>
</configuration>

Supponiamo di avere in deploy un sito di commercio elettronico che utilizza FormsAuthentication come modulo di autenticazione. In questo scenario si potebbero rimuovere immediatamente i moduli WindowsAuthentication e PassportAuthentication (poi Session ;)) e così via...

Technorati tags: HttpModule, ASP.NET

[ASP.NET] DOCTYPE e MIME sono importanti!

Dario Santarelli — Fri, 09 Nov 2007 15:51:00 GMT

Lo scorso aprile ho avuto l'onore di essere uno degli speaker presso il 3° workshop organizzato da DotNetMarche relativamente all'Accessibilità dei siti Web. In quella occasione, tra le varie interessanti riflessioni, sono stati approfonditi molti aspetti teorici e tecnici riguardanti le sfide che uno sviluppatore Web dovrebbe fronteggiare per realizzare applicazioni conformi a standard di accessibilità riconosciuti a livello sia nazionale che internazionale.
Purtroppo, navigando in diversi siti marchiati dalla PA e non solo, ancora oggi si può notare come la maggioranza degli sviluppatori Web non diano sufficiente peso all'importanza di renderizzare contenuti XHTML (almeno) strutturalmente corretti in base ai DOCTYPE dichiarati.
Probabilmente, per un certo verso si fa sentire ancora quella che molti definiscono come una "mancanza" dei principali vendor dei browser visuali, che tramite il DOCTYPE sniffing permettono mirabilmente di correggere al volo degli errori concettuali e strutturali nel rendering dei documenti Web, rifugiandosi in modalità più o meno standard/retrocompatibili (*), per la precisione:

IE/Netscape modes: Standards - Quirks
Firefox/Opera modes: Full Standards - Almost Standards - Quirks

(Notare come Firefox e Opera siano più bacchettoni specificando due sottotipi (Full e Almost) dello Standards mode:
http://developer.mozilla.org/en/docs/Mozilla%27s_DOCTYPE_sniffing)

Il tutto, chiaramente, a danno dell'accessibilità. Utilizzare XHTML significa anzitutto adottare la filosofia "separazione tra contenuto (XML) e presentazione (CSS)" e tutti sappiamo come ciò sia oggi consigliabile da un punto di vista tecnico ed obbligatorio per i siti Web destinati alla PA nonché ad un utenza diversamente abile. In questo senso, le specifiche W3C hanno sempre insistito molto nei confronti dei vendor di Authoring Tools, non solo finalizzati allo sviluppo Web (vedi le specifiche ATAG), con lo scopo di spingere verso l'utilizzo di application/xhtml+xml come MIME type predefinito (non supportato tra l'altro da IE) nella fornitura di contenuti XHTML. In effetti, il well-forming strutturale di un documento XHTML è il primissimo passo verso la cosiddetta "standard conformance" ed il raggiungimento di contenuti accessibili.
Interessante in questo contesto è il percorso di ASP.NET: dalla completa assenza del supporto ad XHTML della versione 1.x si è passati al supporto nativo nelle versioni successive, scegliendo XHTML 1.0 Transitional come DOCTYPE predefinito (per far contenti tutti) ed integrando un utile strumento di validazione a partire da VS2005 (da prendere però con le molle in quanto non permette di controllare XHTML renderizzato lato client). Il MIME type di default invece è rimasto lo stesso: text/html. In altre parole il comportamento di default è: "erogare contenuti xhtml mantenendo la 'genericità' dei documenti html".
Nella speranza che tutti un giorno sviluppino seguendo specifiche rigorose come XHTML 1.0 Strict / 1.1 (meglio), riporto un esempio di HttpModule che implementa uno dei workaround più consigliati per erogare contenuti application/xhtml+xml, chiaramente qualora lo user agent richiedente dichiari di supportarlo:

public class ContentTypeModule : IHttpModule
{
public void Init(System.Web.HttpApplication application)
{
application.PreSendRequestHeaders += new EventHandler(this.Application_PreSendRequestHeaders);
}

private void Application_PreSendRequestHeaders(object sender, System.EventArgs e)
{
    HttpApplication app = ((HttpApplication)(sender));
    HttpContext context = app.Context;
    if (Array.IndexOf(context.Request.AcceptTypes,"application/xhtml+xml") > -1)
    {
      context.Response.ContentType = "application/xhtml+xml";
    }
   }

   public void Dispose() { }
}

Due curiosità:

Application_PreSendRequestHeaders è un evento disponibile anche nel Global.asax
Tramite l'array di stringhe Request.AcceptTypes possiamo osservare tutti i MIME Types accettati da un particolare browser: IE ad esempio è il più furbo poiché dichiara semplicemente " */* " (ovvero: accetto tutto!!!) mentre ad esempio Firefox dichiara, in ordine di preferenza, text/xml, application/xml, application/xhtml+xml ... e */* alla fine.

(*) Per capire in maniera approfondita la differenza tra Standard e Quirks mode consiglio vivamente la lettura di questo completissimo articolo: http://www.quirksmode.org/css/quirksmode.html (la tabella in fondo chiarisce ogni dubbio sulla sostanziale differenza esistente tra il rendering standard e quello retrocompatibile)

Technorati tags: XHTML, W3C

ASP.NET: alcuni "Security How-Tos" fondamentali

Dario Santarelli — Wed, 24 Oct 2007 22:46:38 GMT

Ogni tanto bisogna riproporre questi link, giusto per tornare con i piedi per terra e soprattutto per diminuire la probabilità di diventare una delle vittime di Raf :)

How To: Protect From Injection Attacks in ASP.NET

How To: Use Regular Expressions to Constrain Input in ASP.NET

How To: Prevent Cross-Site Scripting in ASP.NET

Questo ed altro su uno dei vademecum dello sviluppatore .NET più utili in assoluto:

http://www.guidancelibrary.com/guidanceexplorerbeta/ (Web)
http://www.codeplex.com/guidanceExplorer (Windows Application - Codeplex)

Technorati tags: ASP.NET , Security