L'objectif de cette propriété est d'offrir une compatibilité à rebours avec l'ASP classique et a été écartée en faveur de la propriété BufferOutput. Avec ASP.NET, il est préférable d'utiliser BufferOutput plutôt que Buffer.

Une différence importante entre la propriété Response.Buffer en ASP classique et les propriétés Buffer et BufferOutput dans ASP.NET, c'est qu'en ASP classique, vous ne pouviez pas modifier la propriété Buffer pour le contenu non encore envoyé au navigateur sans entraîner une erreur. Dans ASP.NET, étant donné qu'il s'agit d'un outil compilé (et non pas interprété), vous pouvez modifier la propriété Buffer ou BufferOutput à tout moment, et la modification n'affecte que le mode de mise en mémoire. Cela offre aux développeurs une flexibilité bien plus grande en termes de mise en mémoire du résultat et du moment pour le faire. Reportez-vous à l'exemple concernant BufferOutput pour une démonstration.

Dans cet exemple, on donne à la propriété BufferOutput la valeur False , puis on effectue 50 boucles, en inscrivant une période dans le résultat HTTP à chaque itération de boucle. On inscrit également le même résultat dans la propriété Text du contrôle Message Label. Pour les 10 premières et les 21 dernières itérations, la propriété BufferOutput a la valeur False ; pour les itérations 11 à 29, elle a la valeur True .

Sub Page_Load(  )
   Response.BufferOutput = False
   Dim i As Integer
   For i = 1 To 50
      If (i > 10 And i < 30) Then
         Response.BufferOutput = True
      Else
         Response.BufferOutput = False
      End If
      System.Threading.Thread.Sleep(500)
      Response.Write(".")
      Message.Text &= "."
      'Response.Flush
   Next
   Response.Write("<br/>Done!<br/>")
   Message.Text &= "<br/>Done!<br/>"
End Sub

Le contenu lié au code aura à peu près l'aspect suivant:

.................................................. Effectué ! .................................................. Effectué !
En principe, on verra apparaître les périodes de la première ligne l'une après l'autre jusqu'à la dixième, suivies d'une pause, puis de 20 autres, suivies l'une après l'autre par le reste et finalement par l'instruction « Effectué ! ». Le même résultat lié au contrôle ASP.NET Label (sous forme de <span> HTML) apparaîtra en une seule fois, étant donné que le contenu lié aux contrôles du serveur n'est pas envoyé au client tant que le contrôle n'est pas effectué. Cela signifie que pour chaque boucle de l'exemple, le code se contente d'ajouter à une propriété du contrôle qui sera effectué plus tard, alors que le texte envoyé à l'aide de Response.Write est envoyé au navigateur immédiatement après l'arrêt de la mise en mémoire. Vous pouvez observer un comportement similaire en distinguant les lignes Response.BufferOutput de l'exemple (à l'aide d'un guillemet ( ' ) simple placé en début de ligne), et en banalisant la ligne Response.Flush. Le fait de distinguer et de banaliser permet d'éliminer la pause d'affichage décrite précédemment. Il est possible d'interrompre le traitement d'une requête ASP.NET pendant un certain nombre de millièmes de secondes à l'aide de la méthode Shared (static) Thread.Sleep. Cela peut être utile lorsque, pour une raison ou pour une autre, il vous faut attendre pendant le traitement. Cependant, le recours à une telle méthode peut avoir un effet sur le temps de traitement total de chacune des requêtes. Pour les applications nécessitant une grande souplesse de fonctionnement, cela peut avoir des effets inacceptables sur le rendement général de l'application, étant donné que seul un nombre limité d'associations de serveurs est disponible pour traiter les requêtes.
Pour éviter de fournir de façon explicite l'espace de noms lorsque vous utilisez Thread.Sleep, ajoutez la ligne suivante à la page, juste après la déclaration @ Page :

Cette propriété est l'équivalent ASP.NET de la propriété Buffer en ASP classique et lui est préférée pour les nouveaux développements.

Dans cet exemple, on récupère une instance de la classe HttpCachePolicy dans une variable locale, on fixe l'heure d'expiration de la page à celle de fin de traitement augmentée de deux minutes, puis on assigne à la fonction cache de la page la valeur Public . Enfin, la propriété Text du contrôle Message Label est mise à l'heure considérée.

Sub Page_Load(  )
   Dim myCachePol As HttpCachePolicy
   myCachePol = Response.Cache
   myCachePol.SetExpires(DateTime.Now.AddSeconds(120))
   myCachePol.SetCacheability(HttpCacheability.Public)
   Message.Text = Now.ToString(  )
End Sub

Normalement, la page affiche la date et l'heure considérées. En cas de mise à jour, le résultat doit en principe rester le même pendant deux minutes.

L'objet HttpCachePolicy renvoyé par cette propriété constitue la méthode préférée en ASP.NET pour modifier la politique de cache d'une page donnée. HttpCachePolicy fournit la fonctionnalité correspondant aux propriétés CacheControl, Expires et ExpiresAbsolute de l'ASP classique. Par exemple, la classe HttpCachePolicy vous permet d'empêcher de façon explicite le serveur de mettre en cache la réponse en question, tout en permettant la mise en cache aval de la réponse. Vous pouvez également définir les politiques de mise en cache du contenu d'une page au moyen de la directive @ OutputCache et de ses attributs, même si cette méthode permet un contrôle moins détaillé que celui fourni par les méthodes de la classe HttpCachePolicy . La mise en cache au moyen de la directive @ OutputCache est décrite dans le chapitre 3.

Sub Page_Load(  )
   Response.CacheControl = "Public"
   Response.Expires = 2
   Message.Text = Now.ToString(  )
End Sub

Le code ci-dessus doit en principe afficher le même résultat que l'exemple précédent.

Cette propriété a été écartée en faveur des méthodes de classe HttpCacheability .

Dans l'exemple ci-dessous, on donne au jeu de caractères de la réponse HTTP la valeur Windows-1255 (veuillez noter que, comme son nom l'indique, ce jeu de caractères n'est disponible que sur Internet Explorer pour les clients Windows et peut entraîner des erreurs d'affichage de page avec les autres navigateurs ou avec ceux qui utilisent d'autres systèmes d'exploitation). Puis, on inscrit la valeur du jeu de caractères dans la propriété Text du contrôle Message Label. Pour voir la différence entre ce jeu de caractères et le jeu de caractères par défaut utf-8, chargez la page dans Internet Explorer et faites ressortir la ligne qui définit la propriété Charset, enregistrez la page et rechargez-la dans le navigateur.

Si vous essayez de modifier cette propriété une fois que les en-têtes HTTP ont été envoyés au navigateur, une HttpException s'affichera. Cela risque fort de se produire si vous désactivez la mise en mémoire du résultat à l'aide de la propriété BufferOutput et que vous écrivez ensuite le contenu dans le navigateur à l'aide de Response.Write.

Si le jeu de caractères indiqué par la propriété Charset n'est pas adapté au navigateur utilisé par le client, il sera ignoré et le jeu de caractères par défaut correspondant à ce navigateur lui sera préféré. Comme indiqué précédemment, le fait d'utiliser le jeu de caractères par défaut peut entraîner un affichage de la page différent de ce qui était prévu.

Dans cet exemple, on utilise les propriétés de l'instance de classe Encoding renvoyée par la propriété ContentEncoding pour afficher le nom explicite et le nom enregistré (IANA) du codage considéré.

La propriété ContentEncoding est nouvelle dans ASP.NET et fournit une interface plus riche pour l'examen et la modification du jeu de caractères et des informations de page de code de la réponse considérée. Elle représente également la seule manière de convertir une chaîne à codage de caractère en une autre à codage différent (par exemple, Unicode à ANSI).

Dans l'exemple suivant, on affiche le type de contenu MIME considéré dans le navigateur du client.

La propriété ContentType est très importante, étant donné qu'elle vous permet d'envoyer du contenu au navigateur du client différent du HTML par défaut. Par exemple, si vous souhaitez utiliser la méthode Response.BinaryWrite pour envoyer des données d'image binaire au navigateur du client, vous devez également donner à la propriété ContentType le type MIME approprié (« image/jpg » ou « image/gif », par exemple). Reportez-vous à l'exemple BinaryWrite pour découvrir la façon de faire correspondante.

Cette propriété permet d'assurer une compatibilité à rebours avec les applications ASP classiques. Elle a été écartée en faveur des méthodes de l'instance HttpCachePolicy renvoyées par la propriété Cache.

Dans l'exemple suivant, on place la réponse considérée en mode cache à l'aide de la propriété CacheControl, puis on donne au délai d'expiration définitive la valeur 30 secondes à partir de l'instant considéré.

Cette méthode permet d'assurer une compatibilité à rebours avec les applications ASP classiques. Elle a été écartée au profit des méthodes de l'instance HttpCachePolicy renvoyées par la propriété Cache.

Dans cet exemple, on vérifie la propriété IsClientConnected avant de commencer un traitement prolongé afin d'éviter le coût que représente l'exécution de la tâche si le client n'est plus connecté. Si la propriété renvoie False , le code invoque la méthode Response.End. Même si le client s'est déconnecté et ne peut plus recevoir le contenu mis en mémoire (qui est envoyé lorsqu'on invoque la méthode End), le fait d'invoquer la méthode End reste une bonne idée, étant donné qu'elle interrompra le traitement de la page et déclenchera l'événement Application_EndRequest. Si vous avez écrit du code de nettoyage pour la page exécutée par le gestionnaire d'événement Application_EndRequest, le fait d'invoquer Response.End permettra d'exécuter le code de nettoyage, même si le client est déconnecté.

La propriété IsClientConnected est particulièrement utile pour les processus à long terme qui nécessitent une quantité appréciable de ressources de traitement sur le serveur. Le fait d'interroger la propriété IsClientConnected avant de commencer un traitement lourd, ou celui d'interroger la propriété de façon périodique en cours de traitement, vous permet d'éviter de poursuivre un traitement si le client s'est déconnecté pour une raison ou pour une autre.

Dans cet exemple, on déclare une variable locale de type TextWriter, on récupère une instance de TextWriter à partir de la propriété Output, puis on utilise la méthode WriteLine pour inscrire le texte « Bonjour tout le monde ! » dans le flux de sortie. La méthode WriteLine inscrit le texte indiqué (ou une représentation des types de données hors chaines sous forme de texte), ainsi qu'une fin de ligne, à l'aide de la propriété NewLine du TextWriter. Si l'on ne définit pas la propriété NewLine, le caractère de fin de ligne affectera le formatage du texte envoyé au navigateur. Cependant, il ne modifiera pas le formatage du résultat fourni par le navigateur, étant donné que les navigateurs ignorent en général les espaces de type fin de ligne non HTML lorsqu'ils interprètent du code HTML.

La propriété Output constitue une alternative à la méthode Response.Write pour l'affichage de texte dans le flux de sortie. Vous pouvez également transmettre l'instance TextWriter obtenue de la propriété Output à une méthode de composant personnalisé afin de permettre à ce composant d'inscrire du texte directement dans le flux de sortie de la réponse considérée.

Au même titre que la méthode Response.Write, le résultat de l'inscription de texte dans le flux de sortie à l'aide du TextWriter renvoyé par la propriété Output dépend de l'emplacement du code qui sert à inscrire le texte. Par exemple, dans le code ci-dessus, le texte « Bonjour tout le monde ! » apparaîtra avant tout code HTML statique dans la page affichée. Et ce, parce que dans ce cas, le résultat lié au TextWriter et à la méthode Response.Write est traité avant d'appliquer les contrôles à la page. Pour obtenir l'apparition en ligne du résultat de l'instance TextWriter ou Response.Write, vous pouvez placer le code ci-dessus dans un bloc interpréteur <% %> là où vous souhaitez voir apparaître le résultat. Une meilleure approche pour localiser de façon précise un résultat dans ASP.NET consiste à ajouter un contrôle de serveur Literal ASP.NET à l'endroit du fichier où vous souhaitez voir apparaître le résultat et à transmettre le texte de résultat désiré à la propriété Text du contrôle Literal. Pour utiliser la classe TextWriter sans ajouter de façon explicite l'espace de noms System.IO à la déclaration de variable, vous pouvez ajouter la directive @ Import directement en dessous de la directive @ Page avec l'attribut Namespace placé sur System.IO, comme le montre l'exemple suivant:

<% @ Import Namespace="System.IO" %>

La propriété OutputStream constitue une alternative à la méthode Response.BinaryWrite pour afficher du contenu binaire dans le flux de sortie. Vous pouvez également transférer l'instance Stream récupérée à partir de la propriété OutputStream à la méthode d'un composant personnalisé afin de permettre à ce composant d'inscrire du code binaire directement dans le flux de sortie de la réponse considérée.

Cette propriété permet d'assurer une compatibilité à rebours avec les applications ASP classiques et a été écartée dans ASP.NET en faveur de la propriété StatusDescription. Contrairement à la propriété Status, les propriétés StatusCode et StatusDescription vous permettent de contrôler la portion de code d'état numérique de la ligne d'état et la description de texte de façon individuelle.

Cet exemple utilise les propriétés StatusCode et StatusDescription pour envoyer un message d'état HTTP au client. La méthode Response.End interrompt tout traitement ultérieur et envoie au client le résultat se trouvant en mémoire.

Au même titre que les autres propriétés qui définissent des en-têtes de réponse HTTP, cette propriété ne peut pas être définie une fois que le code HTTP de corps a été envoyé au client à l'aide des méthodes Response.Write ou assimilées, après interruption de la mise en mémoire.

Reportez-vous à l'exemple de la propriété StatusCode.

Au même titre que les autres propriété qui définissent des en-têtes de réponse http, cette propriété ne peut plus être définie une fois que le corps HTTP a été envoyé au client (à l'aide des méthodes de type Response.Write ou de méthodes assimilées), après interruption de la mise en mémoire.

L'exemple suivant inscrit le texte « Bonjour tout le monde ! » dans le résultat (qui est mis en mémoire par défaut) et donne à SuppressContent la valeur True si bien qu'aucun résultat n'est envoyé au client.

Etant donné que SuppressContent empêche de renvoyer un résultat quelconque au client (y compris les messages d'erreur), la méthode Response.Close (qui referme la connexion réseau avec le client) doit être invoquée pour empêcher le navigateur du client de rester ouvert indéfiniment.

Cet exemple crée un cookie de login, définit une heure d'expiration du cookie 30 minutes après l'heure considérée et ajoute le cookie à la collection Cookies.

Contrairement à l'ASP classique, les collections d'ASP.NET démarrent à zéro, si bien que, quelle que soit la collection ou le tableau considéré, sa première valeur est 0 et non pas 1. Il est particulièrement important de s'en rappeler lorsque l'on souhaite récupérer des valeurs à l'aide de l'index correspondant.

Cet exemple montre comment utiliser la méthode AddCacheItemDependencies pour définir un nombre de clés cache en fonction du cache de sortie de la réponse considérée. Si l'un des éléments cache représentés par ces clés est modifié, le cache de sortie est invalidé et la page est mise à jour à l'aide de Response.Redirect.

La méthode AddCacheItemDependencies est utile lorsque vous souhaitez mettre en cache le résultat d'une page, mais la page elle-même dépend de la valeur de plusieurs éléments stockés dans le cache ASP.NET. Plutôt que de mettre en cache la page pour une durée très courte afin d'éviter la péremption des données, vous pouvez utiliser AddCacheItemDependencies pour annuler automatiquement la mise en cache de résultat lorsque les conditions changent.

Cet exemple montre comment utiliser la méthode AddCacheItemDependencies pour définir une clé de cache en fonction du cache de sortie de la réponse considérée. Si l'élément cache représenté par cette clé est modifié, le cache de sortie est annulé et la page est mise à jour à l'aide de Response.Redirect.

La méthode AddCacheItemDependency fournit la même fonctionnalité que la méthode AddCacheItemDependencies, mais pour un élément cache individuel plutôt que pour un groupe d'entre eux.

Cet exemple montre comment utiliser la méthode AddFileDependencies pour définir un nombre de fichiers en fonction du cache de sortie de la réponse considérée. Si l'un de ces fichiers est modifié, le cache de sortie est invalidé.

La méthode AddFileDependencies est utile lorsque vous souhaitez mettre en cache le résultat d'une page, mais la page elle-même dépend de la valeur de plusieurs fichiers sur le serveur Web (auquel on peut accéder à l'aide d'un chemin de fichier depuis le serveur Web). Plutôt que de mettre en cache la page pour une durée très courte afin d'éviter la péremption des données, vous pouvez utiliser AddFileDependencies pour invalider automatiquement la mise en cache de résultat lorsque les conditions changent.

L'exemple ci-dessous montre comment utiliser la méthode AddFileDependency pour définir un fichier en fonction du cache de sortie de la réponse considérée. Si le fichier est modifié, le cache de sortie est invalidé.

<%@ Page Language="vb" %>
<%@ OutputCache Duration="300" VaryByParam="None" %>
<html>
   <head>
      <title>Adding a file dependency in ASP.NET</title>
      <script runat="server">
         Sub Page_Load(  )
            Response.AddFileDependency(Server.MapPath("dep.txt"))
            Message.Text = DateTime.Now.ToString(  )
         End Sub
      </script>
   </head>
<body>
   <asp:label id="Message" runat="server"/>
</body>
</html>

Le nom de fichier dep.txt figurant dans le code ci-dessus doit résider dans le même répertoire que la page. Vous êtes libre de choisir les contenus de la page. Si le contenu du fichier est modifié, le cache sera invalidé.

La méthode AddFileDependency fournit la même fonctionnalité que la méthode AddFileDependencies, mais pour un fichier individuel plutôt que pour un groupe d'entre eux.

La propriété AddHeader fournit une compatibilité à rebours avec les applications ASP classiques. Cette propriété a été écartée en faveur de la nouvelle méthode AppendHeader.

Dans cet exemple, on donne à l'en-tête HTTP Content-Type la valeur « text/xml » puis on affiche la nouvelle valeur en donnant à la propriété Text du contrôle Message Label la valeur de la propriété ContentType. En conséquence, le résultat de la page est traité en tant que code XML.

Lorsque vous utilisez cette méthode avec des en-têtes HTTP liés à la politique de mise en cache, si des paramètres plus restrictifs sont appliqués par utilisation des API de cache ASP.NET, ceux-ci seront prioritaires par rapport à ceux appliqués à l'aide de AppendHeader.

Dans l'exemple suivant, on inscrit un message dans le journal IIS de l'application à laquelle appartient la page, puis on inscrit un message dans le contrôle Message Label ASP.NET indiquant que le message a été rédigé:

Sub Page_Load(  )
   Response.AppendToLog("Hello from Page_Load!")
   Message.Text = "Message written to IIS Log!"
End Sub

L'entrée de journal IIS générée par l'exemple ci-dessus a l'aspect suivant:

2001-10-14 00:13:14 127.0.0.1 - 127.0.0.1 80 GET
/ASPdotNET_iaN/Chapter_17/AppendToLog.aspx
Hello+from+Page_Load! 200 
BrowserString

Contrairement à la méthode AppendToLog en ASP classique, qui était limitée à 80 caractères par appel, avec ASP.NET vous pouvez inscrire autant de texte que vous le souhaitez dans le journal à l'aide de AppendToLog. Les fichiers journaux IIS sont situés par défaut dans %windir% \System32\LogFiles\W3SVC x \ex date .log, où %windir% est le nom du répertoire Windows, x est le nombre de sites Web du journal (correspondant au nom de Metabase IIS de l'application en question) et date est la date de création du fichier journal.

Dans l'exemple suivant, on récupère un chemin virtuel contenant le SessionID et on affiche le chemin à l'aide de la propriété Text du contrôle Message Label:

Sub Page_Load(  )
   Dim NewPath As String
   NewPath = Response.ApplyAppPathModifier(Request.Path)
   Message.Text = "Modified virtual path = " & NewPath
End Sub

Le fichier web.config servant à définir le gestionnaire d'état de session pour utiliser des sessions sans cookies figure ci-dessous:

<configuration>
   <system.web>
      <sessionState mode="InProc" cookieless="true"/>
   </system.web>
</configuration>

Cette méthode est très utile en cas d'usage de la fonctionnalité d'état de session sans cookies qui est nouvelle dans ASP.NET. Si l'attribut sans cookies de la section config sessionState dans web.config n'a pas la valeur True , cette méthode renverra simplement le chemin virtuel transmis sans modification.

Voici un exemple de BinaryWrite:

Cette méthode est particulièrement utile pour inscrire du contenu binaire récupéré à partir d'une base de données dans le navigateur. Lorsqu'on introduit des données autres que du texte (graphiques, etc.) dans le navigateur, on veillera à affecter le type MIME approprié à la propriété Response.ContentType du type d'image que l'on envoie(« image/jpg » par exemple).

La méthode Clear efface l'ensemble du code en mémoire à un moment donné, mais n'efface pas les en-têtes de réponse HTTP. Si la mise en mémoire du résultat est inactivée en donnant à la propriété BufferOutput la valeur False , cette méthode n'aura aucun effet, étant donné qu'elle n'efface que le contenu mis en mémoire. Ce n'est pas le cas en ASP classique, où le fait d'invoquer Clear lorsque la mise en mémoire est désactivée entraîne une erreur.

Dans cet exemple, on inscrit un message de texte à l'aide de Response.Write puis on efface le résultat mis en mémoire à l'aide de Response.Clear. Si la mise en mémoire est activée, le message de texte ne sera jamais envoyé au navigateur.

La méthode ClearContent efface l'ensemble du code en mémoire à un moment donné, mais n'efface pas les en-têtes de réponse HTTP. Les en-têtes HTTP peuvent être effacés à l'aide de la méthode ClearHeaders. Si la mise en mémoire du résultat a été désactivée en donnant à la propriété BufferOutput la valeur False , la méthode ClearContent n'aura aucun effet, étant donné qu'elle n'efface que le contenu mis en mémoire.

Dans cet exemple, on donne à l'en-tête HTTP Content-Type la valeur « text/xml », on efface les en-têtes HTTP à l'aide de la méthode ClearHeaders, puis on inscrit la valeur de la propriété Response.ContentType dans la propriété Text du contrôle Message ASP.NET Label. Le Content-Type affiché par défaut est « text/html ».

La méthode ClearContent n'efface que les en-têtes de réponse HTTP, mais pas le contenu mis en mémoire.

Reportez-vous à l'exemple concernant la propriété SuppressContent.

La méthode Close peut servir à refermer de façon immédiate la prise de réseau de la réponse considérée. Ce mode de fermeture entraînera généralement l'affichage d'un message d'erreur (du type « serveur introuvable ») dans le navigateur du client.

Dans l'exemple ci-dessous, on inscrit le texte « Bonjour tout le monde ! » dans le navigateur, on invoque Response.End, puis on essaie de donner à la propriété Text du contrôle Message ASP.NET Label la valeur « Bonjour tout le monde ! » Cependant, ce code ne sera pas exécuté, étant donné que la méthode End interrompt immédiatement le traitement de la page.

Sub Page_Load(  )
   Response.Write(« Bonjour tout le monde ! »)
   Response.End(  )
   Message.Text = « Bonjour tout le monde ! »
End Sub

En réalité, le code ci-dessus n'entraînera que l'affichage du message « Bonjour tout le monde ! » dans le navigateur, étant donné que ni le code HTML statique, ni les contrôles n'apparaîtront sur la page.

Lorsqu'on invoque la méthode End, en plus de l'envoi au client du résultat mis en mémoire et de l'interruption du traitement, on déclenche l'événement Application_EndRequest.

Reportez-vous à l'exemple correspondant à la propriété BufferOutput. Si vous faites ressortir les lignes qui donnent à BufferOutput la valeur False et que vous banalisez la ligne qui invoque Response.Flush, vous vous rendrez compte que la méthode Flush vous permet d'envoyer de façon explicite au navigateur du contenu mis en mémoire.

Le fait que la mise en mémoire s'effectue par défaut dans ASP.NET rend la méthode Flush particulièrement utile. Plutôt que de désactiver la mise en mémoire, ce qui a pour effet d'envoyer immédiatement au navigateur tout le contenu envoyé à l'aide de Response.Write, vous pouvez utiliser Response.Flush pour envoyer du contenu par morceaux ou pour vous assurer de la fin définitive d'une opération avant d'envoyer le contenu mis en mémoire à un moment donné.

Vous pouvez aussi combiner les utilisations de Response.Flush et de Response.Clear pour effectuer la vérification préalable du contenu avant de l'envoyer au navigateur. Si un jeu de calculs ou de résultats donné rencontre une erreur, vous pouvez invoquer Response.Clear pour effacer le résultat gênant et le remplacer ensuite par un message d'erreur ou par un contenu différent. Si le résultat vous convient, vous pouvez invoquer Response.Flush pour envoyer le résultat mis en mémoire au navigateur et continuer ensuite le traitement.

Dans l'exemple suivant, on définit un en-tête PICS pour lequel RSAC est l'organisme d'évaluation, on fixe la période d'évaluation du 1/8/2001 au 28/2/2002 et on définit les catégories de la façon suivante:

• Violence - 1
• Sexe - 2
• Langage pour adultes - 3
• Nudité - 4

Sub Page_Load(  )
   Dim PICSLabel As String
   PICSLabel &= "(PICS-1.1 <http://www.rsac.org/ratingsv01.html> "
   PICSLabel &= "labels on " & Chr(34)
   PICSLabel &= "2001.08.01T06:00-0000" & Chr(34)
   PICSLabel &= " until " & Chr(34)
   PICSLabel &= "2002.02.28T23:59-0000" & Chr(34)
   PICSLabel &= " ratings (V 1 S 2 L 3 N 4))"
   Response.PICS(PICSLabel)
   Message.Text = PICSLabel
End Sub

L'en-tête PICS-Label sert à évaluer le contenu d'un site. Les utilisateurs peuvent configurer leurs navigateurs pour interdire l'affichage de sites qui envoient des en-têtes PICS-Label et dont les évaluations indiquent que le site contient un haut niveau de contenu dans l'une des catégories que le navigateur est censé évaluer. Des informations supplémentaires sur les normes PICS en matière d'évaluation de contenus sont disponibles sur le site web du World Wide Web Consortium: http://www.w3c.org.

Dans cet exemple, on redirige la requête considérée vers BufferOutput.aspx et on demande à ASP.NET d'interrompre le traitement de la page considérée:

Sauf si la page depuis laquelle vous invoquez Response.Redirect nécessite un traitement supplémentaire, donnez toujours la valeur True au deuxième argument de Response.Redirect afin d'éviter de gaspiller des ressources de serveur en continuant à traiter la page considérée. Cette fonction est nouvelle dans ASP.NET. Lorsque l'on invoque Response.Redirect uniquement à l'aide de l'argument url , le traitement de la page en question est interrompu de façon automatique.

Veuillez noter que lorsque vous redirigez vers une page telle que BufferOutput.aspx dans laquelle la mise en mémoire est désactivée, ou vers une page qui utilise Response.Flush, la redirection ne s'arrêtera que lorsque la page cible a achevé le traitement. Cela signifie que tout le contenu de la page cible apparaîtra en même temps, plutôt que petit à petit à partir de la mémoire tampon.

Cet exemple crée un tableau de Chars, définit les valeurs des Chars, puis parcourt le tableau et affiche son contenu à l'aide de Response.Write:

Comme indiqué ci-dessus, la méthode Write d'ASP.NET permet d'acquérir un certain nombre de nouvelles implémentations surchargées. Le code ci-dessus peut aussi être écrit à l'aide d'une autre implémentation surchargée qui accepte un tableau de Chars, un index de départ, et le compte de Chars à inscrire, comme le montre l'exemple suivant:

Response.Write(MyChars, 0, 3)

L'implémentation de la méthode Write qui prend Object comme argument profite de la méthode intégrée ToString de la classe d'objet pour afficher la représentation de chaîne de l'objet. ToString est hérité par l'ensemble des classes .NET et, par défaut, renvoie l'espace de noms et le nom de classe de la classe d'objet. Les classes qui souhaitent envoyer d'autres informations les concernant peuvent, pour ce faire, écraser l'implémentation héritée de ToString.

Dans cet exemple, on inscrit les contenus du fichier dep.txt dans le flux de sortie de la réponse considérée.

La méthode WriteFile peut être utilisée de plusieurs (comme des données graphiques) échoueront.