Sample usage for HTTP GET requests:

DigestHttpWebRequest request = newDigestHttpWebRequest(username, password);

HttpWebResponse result = request.GetResponse(uri); 

Sample usage for HTTP POST requests:

DigestHttpWebRequest request = newDigestHttpWebRequest(username, password);

request.Method = WebRequestMethods.Http.Post;

request.ContentType = "text/plain; charset=utf-8";

request.PostData = Encoding.ASCII.GetBytes(postData);               

HttpWebResponse result = request.GetResponse(uri); 

Applies to
Microsoft .NET Framework 1.1
Microsoft .NET Framework 2.0
Microsoft .NET Framework 3.0
Microsoft .NET Framework 3.5
Microsoft .NET Framework 4.0
Microsoft .NET Framework 4.5

Recientemente he trabajado en un caso en el que tras reiniciar un servidor Windows Server 2003, el servicio IIS Admin Service fallaba en el arranque con el siguiente mensaje de error:

Windows could not start the IIS Admin Service on Local Computer. For more information, review the System Event Log. If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code -2146893813.

 
Adicionalmente, en el log de eventos de sistema se registraba el siguiente error:

Manuel: Event Type: Error
Event Source: Service Control Manager
Event Category: None
Event ID: 7024
Date: 23/05/2012
Time: 11:40:35
User: N/A
Computer: IIS6-Server
Description:
The IIS Admin Service service terminated with service-specific error 2148073483 (0x8009000B).

El código de error 0x8009000B se corresponde a NTE_BAD_KEY_STATE (“Key not valid for use in specified state”o “Clave no válida para utilizar en el estado especificado” en castellano) e indica un error al utilizar unas claves de encriptación.

IIS 6.0 cifra algunos campos del fichero XML de configuración (metabase.xml) con información sensible como contraseñas de cuentas de servicio. Para esto, IIS 6.0 crea un contenedor de claves criptográficas durante la instalación del servicio llamado “Microsoft Internet Information Server”. Este contenedor de claves está almacenado físicamente en el fichero %ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys\c2319c42033a5ca7f44e731bfd3fa2b5_<MachineGuid>. El valor de MachineGuid se puede obtener de la siguiente clave del registro y será distinto en cada servidor: 
  

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography]

"MachineGuid"="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

 
Con la herramienta certutil podemos volcar cierta información de este contenedor de claves, y entre otras cosas podemos ver que las claves privadas no son exportables, por lo que el fichero metabase.xml cifrado con estas claves únicamente podrá ser descifrado en el mismo servidor donde fue creado. 
  

C:\WINDOWS\system32>certutil -v -key "Microsoft Internet Information Server"

Microsoft Strong Cryptographic Provider:

Microsoft Internet Information Server

c2319c42033a5ca7f44e731bfd3fa2b5_809cf898-e06e-4673-83e2-6200ef0291cc

AT_SIGNATURE:

Key Id Hash(sha1): d0 31 ed 58 81 bf 61 b9 a3 76 99 cb 17 ad ce 88 ff b7 b8 cd

Container Public Key:

000030 48 02 41 00 cd c2 bab5 47 a7 2b 2f 57 4b ae

0010a7 fe 26 9c a2 ed f3 f958 36 df 8f 35 31 1c c0

002032 2c 35 8c 42 68 84 0dc2 4d dd 9a fd 5d 87 0f

0030b2 b9 33 d4 1b bc 62 647c bd d7 6c 59 6e c1 85

0040b3 46 73 2c 59 02 03 0100 01

Private key is NOT exportable

AT_KEYEXCHANGE:

Key Id Hash(sha1): 4f 50 e1 14 9f 63 73 0b ef ae 7c 34 e5 1d 6b d2 eb 1b 59 27

Container Public Key:

000030 48 02 41 00 a3 aa e0ee 9f 45 e9 b4 6c 4d 11

001044 96 39 f8 f6 51 ec 9014 60 1f 57 6e 10 d2 f4

002069 4c c1 1f 09 f5 69 e0fd 75 67 40 00 0d a0 4a

00307d c3 b5 a1 40 b9 20 a65a 3e 1e e9 28 bd aa 2c

00406e 62 64 c9 61 02 03 0100 01

Private key is NOT exportable

CertUtil: -key command completed successfully.

 
IIS 6.0 permite generar backups de la metabase exportables/importables a cualquier servidor, para lo que se utiliza una contraseña en lugar de las claves RSA de máquina para cifrar la metabase. Tener un backup de la configuración de IIS protegido con contraseña puede resultar muy útil como veremos más adelante. 
  

 
Volviendo al problema original, el error 0x8009000B al arrancar el servicio IIS Admin Service típicamente se debe a una corrupción del contenedor de claves de IIS, por lo que el servicio no es capaz de descifrar los campos relevantes al leer el fichero de configuración y por consecuencia fallan en el arranque.

Llegados a esta situación, básicamente tenemos tres opciones, que por orden de preferencia son:  

 
1) Restaurar un backup de system state en el que se restauraría una copia intacta del fichero contenedor de claves c2319c42033a5ca7f44e731bfd3fa2b5_<MachineGuid> lo que permitiría volver a arrancar el servicio de IIS Admin Service.
2) Reinstalar IIS y reconfigurarlo desde un backup de la metabase protegido por contraseña que podamos importar después de la reinstalación.   

3) Reinstalar IIS y reconfigurarlo manualmente desde cero.

PROCESO DE REINSTALACIÓN Y RESTAURACIÓN DEL CONTENEDOR DE CLAVES
En caso que fuera necesaria la reinstalación de IIS, los pasos a seguir son los siguientes:

2) Eliminar el fichero contenedor de claves de “Microsoft Internet Information Server” en la ruta“%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys\c2319c42033a5ca7f44e731bfd3fa2b5_<MachineGuid>”.

3) Reinstalar IIS.

4) Importar el backup de la metabase protegido por contraseña.

5) Añadir las cuentas configuradas como identidad de los application pool al grupo de seguridad IIS_WPG (IIS Worker Process Group) de nuevo, dado que el grupo de seguridad se vuelve a crear tras la reinstalación.

 
Si tenemos varios servidores configurados idénticamente, técnicamente es posible importar un backup de la metabase que ha sido exportado desde otro servidor distinto. No obstante, esto implica tener que modificar manualmente algunas cosas adicionales como sincronizar las cuentas IUSR_<serverName> e IWAM_<serverName> y sus contraseñas, o modificar los bindings de los sitios web en caso de que escuchen por IPs distintas en los distintos servidores de la granja.

En definitiva, haced backup del system state y de la metabase regularmente, y espero que nunca tengáis que hacer uso de este post.   

 
- Daniel Mossberg

Recientemente he publicado una serie de artículos en MSDN España abordando una pregunta que recibimos con frecuencia. ¿Cuáles son las diferencias entre los tres modelos de programación de ASP.NET y en que situaciones debo elegir uno de ellos sobre los otros?

Estos son los enlaces a la serie completa:

ASP.NET Web Forms, MVC o Web Pages – Introducción

http://msdn.microsoft.com/es-es/asp.net/hh984851

Parte 1 – ASP.NET Web Forms

http://msdn.microsoft.com/es-es/asp.net/hh984854

Parte 2 – ASP.NET MVC

http://msdn.microsoft.com/es-es/asp.net/hh984855

Parte 3 – ASP.NET Web Pages

http://msdn.microsoft.com/es-es/asp.net/hh984856

Espero que os resulte interesante.

- Daniel Mossberg

Pasados más de tres meses desde mi último post, ya es momento de retomarlo. Hoy voy a escribir sobre un problema con el que me he encontrado en varias ocasiones en los últimos meses. Básicamente, el problema se produce cuando tenemos una aplicación ASP.NET configurada para impersonar al usuario autenticado, y en algún punto de la aplicación se trata de impersonar programáticamente a un usuario distinto. En estas circunstancias, la aplicación va a fallar con el siguiente error:

Exception Details:

System.Web.HttpException: An error occurred while attempting to impersonate. Execution of this request cannot continue.

Stack Trace:

[HttpException (0x80004005): An error occurred while attempting to impersonate. Execution of this request cannot continue.]

System.Web.ImpersonationContext.GetCurrentToken() +8845961

System.Web.ImpersonationContext.get_CurrentThreadTokenExists() +58

System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +193

System.Web.ApplicationStepManager.ResumeSteps(Exception error) +501

System.Web.HttpApplication.System.Web.IHttpAsyncHandler.BeginProcessRequest(HttpContext context, AsyncCallback cb, Object extraData) +123

System.Web.HttpRuntime.ProcessRequestInternal(HttpWorkerRequest wr) +379

…

Básicamente, el problema radica en que al llamar al método Impersonate (o llamando directamente a la API LogonUser que es la que se termina llamando desde Impersonate), se intenta acceder al token del proceso (por ejemplo, w3wp.exe), y la cuenta del usuario autenticado (el que está siendo impersonado debido a la configuración del web.config) no tiene permiso para acceder a dicho token.

Por lo tanto, para poder impersonar una cuenta distinta programáticamente, necesitamos deshacer la impersonación inicial antes de impersonar una cuenta distinto. Para ello, podemos llamar a la API RevertToSelf para deshacer la impersonación antes de llamar a LogonUser.

En el siguiente ejemplo se ilustra cómo podríamos hacerlo:

const int LOGON32_PROVIDER_DEFAULT = 0;

const int LOGON32_LOGON_INTERACTIVE = 2;

const int SecurityImpersonation = 2;

int win32ErrorNumber = 0;

//Mostramos por pantalla la identidad inicial (la impersonada mediante en el web.config):

Response.Write("Identidad inicial: " + WindowsIdentity.GetCurrent().Name.ToString() + "<BR>");

//Guardamos esa identidad inicial para poder restaurarlo posteriormente

WindowsIdentity _initialIdentity = WindowsIdentity.GetCurrent();

//Llamamos a la API "RevertToSelf" para deshacer la impersonación configurada en el web.config:

RevertToSelf();

//Volvemos a mostrar la identidad, y ahora vemos que ha cambiado a la identidad del application

//pool: (NETWORK SERVICE) por defecto.

Response.Write("Después de llamar a RevertToSelf: " + WindowsIdentity.GetCurrent().Name.ToString() + "<BR>");

//Realizamos la impersonación deseada.

IntPtr _tokenHandle = IntPtr.Zero;

IntPtr _dupeTokenHandle = IntPtr.Zero;

string _domainname = "CONTOSO";

string _username = "demo";       

string _password = "P@ssw0rd!";

if (!LogonUser(_username, _domainname, _password, LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT, out _tokenHandle))

{

    win32ErrorNumber = System.Runtime.InteropServices.Marshal.GetLastWin32Error();

    throw new Exception(win32ErrorNumber.ToString());

}

if (!DuplicateToken(_tokenHandle, SecurityImpersonation, out _dupeTokenHandle))

{

    win32ErrorNumber = System.Runtime.InteropServices.Marshal.GetLastWin32Error();

    CloseHandle(_tokenHandle);

    throw new Exception(win32ErrorNumber.ToString());

}

System.Security.Principal.WindowsIdentity newId = new System.Security.Principal.WindowsIdentity(_dupeTokenHandle);

WindowsImpersonationContext _impersonatedUser = newId.Impersonate();

//Mostramos por pantalla la identidad impersonada

Response.Write("Después de impersonar: " + WindowsIdentity.GetCurrent().Name.ToString() + "<BR>");

//Desahacemos la impersonación cuando ya no lo necesitemos.

_impersonatedUser.Undo();

//Mostramos por pantalla la identidad, que otra vez será la del application pool

Response.Write("Deshacer impersonación: " + WindowsIdentity.GetCurrent().Name.ToString() + "<BR>");

//Volvemos a impersonar con la identidad inicial (la del web.config) que hemos mantenido referenciada

//con la variable _impersonatedUser:

_impersonatedUser = _initialIdentity.Impersonate();

//Por último volvemos a mostrar la identidadMostramos por pantalla la identidad

Response.Write("Volver a impersonación inicial: " + WindowsIdentity.GetCurrent().Name.ToString() + "<BR>");

Tras ejecutar el código anterior, el resultado emitido por pantalla sería el siguiente (en mi ejemplo):

Identidad inicial: CONTOSO\daniel
Después de llamar a RevertToSelf: NT AUTHORITY\NETWORK SERVICE
Después de impersonar: CONTOSO\demo
Deshacer impersonación: NT AUTHORITY\NETWORK SERVICE
Volver a impersonación inicial: CONTOSO\daniel

Estas son las signatures de C# para llamar a las APIs del ejemplo mediante platform invoke:

[DllImport("advapi32.dll", SetLastError = true)]

public static extern bool LogonUser(

    string lpszUsername,

    string lpszDomain,

    string lpszPassword,

    int dwLogonType,

    int dwLogonProvider,

    out IntPtr phToken);

[DllImport("advapi32.dll", SetLastError = true)]

static extern bool RevertToSelf();

[DllImport("advapi32.dll", SetLastError = true)]

public extern static bool DuplicateToken(

    IntPtr ExistingTokenHandle,

    int SECURITY_IMPERSONATION_LEVEL,

    out IntPtr DuplicateTokenHandle);

[DllImport("kernel32.dll", SetLastError = true)]

[return: MarshalAs(UnmanagedType.Bool)]

static extern bool CloseHandle(IntPtr hObject);

Espero que os sea de utilidad.

- Daniel Mossberg

Cuando subimos ficheros a una aplicación ASP.NET, dependiendo del tamaño del fichero y la velocidad de la conexión del cliente, ocasionalmente la subida del fichero puede fallar con el mensaje de error en el cliente de Internet Explorer no puede mostrar la página web, o con alguna de las siguientes excepciones (dependiendo de cómo esté configurado IIS, habitualmente este detalle de la excepción únicamente lo podremos ver en el log de eventos NT del servidor):

HttpException: Request timed out.

HttpException: Maximum request length exceeded.

En estos casos, los parámetros que debéis configurar adecuadamente considerando el tamaño el tiempo de transmisión del fichero son los siguientes:

<httpRuntime executionTimeout="600" maxRequestLength="61440" />

El parámetro de executionTimeout determina el tiempo en segundos que puede ejecutarse una páginas ASP.NET antes de que se lanza una excepción de time out. Por otro lado, el parámetro maxRequestLength determina el tamaño total máximo en bytes de las peticiones HTTP. Debemos configurar estas secciones acorde con los tiempos máximos de carga y tamaños máximos de fichero que queremos que soporte nuestra aplicación.

Los parámetros de la sección <httpRuntime> se pueden configurar a nivel de web.config de aplicación, e incluso a nivel de una página específica de la siguiente manera:

<?xml version="1.0"?>

<configuration>

  ...

  <location path="Default.aspx">

    <!--

      Aquí la configuración específica

      para la página Default.aspx del

      directorio virtual al que aplica

      este web.config.

    -->

    <system.web>

      <httpRuntime

        executionTimeout="600"

        maxRequestLength="61440" />

    </system.web>

  </location>

</configuration>

Esto último es recomendable, dado que aumentar el executionTimeout de todas las páginas de una aplicación puede tener consecuencias negativas. En general, los timeout se deben mantener con valores razonablemente bajos, precisamente para que cuando se produzca una situación de bloqueo, se lanze la excepción y se finalice el procesamiento de la página en poco tiempo de forma que se libere el thread y se puedan atender otras peticiones. Con timeouts elevados se podrían llegar a agotar todos los threads en situaciones de bloqueo, por tardar demasiado en ser liberados.

Por último, si una vez habiendo configurado nuestra aplicación con valores adecaudos, la carga de ficheros sigue fallando con errores HTTP 400 en los logs de IIS y errores de Timer_EntityBody en los logs de HTTP.sys (HTTPERR), probad a desinstalar la funcionalidad de SNP (Scalable Networking Pack) en el servidor web siguiente los instrucciones del siguiente artículo:

An update to turn off default SNP features is available for Windows Server 2003-based and Small Business Server 2003-based computers

http://support.microsoft.com/default.aspx?scid=kb;EN-US;948496

Estos cambios requieren reincio del sistema operativo para entrar en vigor.

Espero que os haya sido de utilidad.

- Daniel Mossberg

Existe cierta confusión con la compatibilidad entre binarios de Silverlight y binarios de .NET, y a más de uno le pilla por sorpresa que en un proyecto de Visual Studio de una aplicación Silverlight, no se pueden referenciar bibliotecas de clases (class library) desarrolladas en .NET de escritorio (para diferenciarlo del .NET de Silverlight). El motivo es que el runtime y la biblioteca de clases de .NET para Silverlight es un subconjunto del runtime y la biblioteca de clases de .NET de escritorio, y por lo tanto no son directamente compatibles.

Se puede migrar el código de las clases .NET a clases .NET para Silverlight, y en ocasiones puede ser tan sencillo como recompilar el mismo código fuente (por ejemplo, como una Silverlight Class Library). En otras ocasiones esta migración no es directa, dado que la biblioteca de clases de Silverlight no contiene todas las clases que la biblioteca de clases del Framework .NET.

.NET Framework Class Library

http://msdn.microsoft.com/en-us/library/ms229335.aspx

.NET Framework Class Library for Silverlight

http://msdn.microsoft.com/en-us/library/cc838194.aspx

Supongamos que queremos reutilizar unas bibliotecas de clases que manejan objetos DataSet, y dado que .NET para Silverlight (hasta la versión Silverlight 4 RC) no contiene el namespace System.Data, no podemos simplemente recompilar el código fuente (fallaría la compilación dado que no estarían implementada ninguna clase DataSet).

Una posible implementación que nos permite reutilizar al máximo nuestras bibliotecas de clases .NET desde aplicaciones Silverlight sería implementar una interfaz, expuesta como un web service, y consumir dicho web service desde la aplicación Silverlight.

De esta manera, todo el código de .NET de escritorio se ejecutará en el servidor web, y la aplicación Silverlight que se ejecutará en el navegador del cliente únicamente representará la capa de presentación.

Os muestro un pequeño ejemplo en C# como prueba de concepto. En este ejemplo, el web service está implementado como un web service de ASP.NET 2.0 (*.asmx), pero considerad la posibilidad de implementarlo como un web service WCF (Windows Communication Foundation), que es la siguiente generación de web services de .NET.

Supongamos que tenemos la siguiente clase en nuestra biblioteca de lógica de negocio. Esta es la clase cuyo código nos gustaría reutilizar en Silverlight, pero dado que hace uso de System.Data no podemos recompilar el código sin más.         

using System;

using System.Data;

namespace SilverlightTest.Web

{

    public class BusinessLogic

    {

        public DataSet getCustomerData(int customerID)

        {

            DataSet dataSet = new DataSet();

            DataTable dataTable = new DataTable();

            dataTable.Columns.Add("Columna 1");

            dataTable.Columns.Add("Columna 2");

            dataTable.Rows.Add(new object[] { "celda 0-0", "celda 0-1" });

            dataTable.Rows.Add(new object[] { "celda 1-0", "celda 1-1" });

            dataTable.Rows.Add(new object[] { "celda 2-0", "celda 2-1" });

            dataTable.Rows.Add(new object[] { "celda 3-0", "celda 3-1" });

            dataSet.Tables.Add(dataTable);

            return dataSet;           

        }

    }

}

Para solventar este problema, podemos crear un web service que exponga el método getCustomerData. En este caso, para hacerlo compatible con Silverlight, convertiremos el objeto DataSet en uno o varios arrays bidimensionales (uno por cada DataTable del DataSet) antes de enviar la respuesta al cliente Silverlight:

using System;

using System.Data;

using System.Web;

using System.Web.Services;

using SilverlightTest.Web;

[WebService]

public class SilverlightInterface : System.Web.Services.WebService

{

    [WebMethod]

    public object[][] getCustomerData(int customerID)

    {

        //Utilizamos la lógica de la biblioteca de clases de .NET de escritorio

        BusinessLogic businessLogic = new BusinessLogic();

        DataSet dataSet = businessLogic.getCustomerData(customerID);

        int x = dataSet.Tables[0].Rows.Count;

        int y = dataSet.Tables[0].Columns.Count;

        //Declaramos y demensionamos el Array

        object[][] dataArray = new object[x][];

        for (int i = 0; i < x; i++)

        {

            dataArray[i] = new object[y];

        }

        //Rellenamos el Array con los datos del DataSet

        for (int i = 0; i < x; i++)

        {

            for (int j = 0; j < y; j++)

            {

                dataArray[i][j] = dataSet.Tables[0].Rows[i][j];

            }

        }

        return dataArray;

    }

}

Por último, desde el cliente Silverlight consumimos el web service de la siguiente manera tras haber incluido la referencia web (que hemos llamado BusinessLogicWS):

public partial class SilverlightPage : UserControl

{

    public SilverlightPage()

    {

        InitializeComponent();       

        //Creamos el objeto proxy para interactuar con el web service

        BusinessLogicWS.SilverlightInterfaceSoapClient wsProxy =

            new BusinessLogicWS.SilverlightInterfaceSoapClient();

        wsProxy.getCustomerDataCompleted

            += new EventHandler

                <BusinessLogicWS.getCustomerDataCompletedEventArgs>

                (getCustomerDataCompletedHandler);

        int CustomerID = 1234;

        //Realizamos la llamada asíncrona al web service       

        wsProxy.getCustomerDataAsync(CustomerID);

    }

    void getCustomerDataCompletedHandler(object sender,

        BusinessLogicWS.getCustomerDataCompletedEventArgs e)

    {

        //Obtenemos los datos de la respuesta del web service

        ObservableCollection<SilverlightTest.BusinessLogicWS.ArrayOfAnyType>

            data = e.Result;           

        //Hacemos algo con esos datos

        for (int i=0; i<data.Count; i++)

        {

            for (int j = 0; j < data[i].Count; j++ )

            {

                Debug.WriteLine(data[i][j].ToString());               

            }

        }

    }

}

De esta forma, hemos construido una interfaz entre la aplicación Silverlight y nuestra biblioteca de clases .NET, pudiendo reutilizar el código de las bibliotecas de clases .NET y solventando los problemas de incompatibilidades entre tipos de datos.

Hasta el próximo post,

- Daniel Mossberg

Este post es la continuación de Cuándo y cómo capturar volcados de memoria en modo Crash

La herramienta Debug Diagnostics Tool se puede descargar desde aquí, tanto la versión de 32-bit como la de 64-bit. En el momento de escribir este post, la herramienta está en la versión 1.1 y está soportada para los siguientes sistemas operativos:

·         Windows 2000 Server

·         Windows Server 2003

·         Windows XP

Es decir, si pretendemos analizar un problema en Windows Server 2008, Windows Server 2008 R2, Windows Vista o Windows 7 es recomendable utilizar otras herramientas, aunque algunas funcionalidades de Debug Diagnostics pueden funcionar en estos sistemas operativos.

Nota

En el caso de los sistemas operativos de 64-bit, es conveniente instalar la versión de DebugDiag en función del proceso que se va a monitorizar. Es decir, si el proceso es de 32-bit, es mejor utilizar la versión de 32-bit de DebugDiag al margen de que Windows sea de 64-bit (de esta forma nos quitamos del medio la capa WOW64 que a veces dificulta la depuración).

DebugDiag nos permite capturar volcados de crash mediante las reglas de crash. Las reglas de crash de DebugDiag permiten adjuntar un depurador a cualquier proceso y configurarlo para que genere volcados en el momento que se produzca una determinada excepción o cuando se finalice el proceso. Estos son los escenarios más comunes:

Volcados de crash de finalización de un proceso

Volcados de excepciones .NET

VOLCADOS DE CRASH DE FINALIZACIÓN DE UN PROCESO

Este es el escenario más común para capturar volcados de crash, y consiste en generar un volcado de memoria en el momento que se produce la excepción no manejada que provoca la finalización del proceso.

Para configurar una regla de crash de estas características debemos posicionarnos en la pestaña [Rules] y posteriormente pulsar sobre el botón  [Add Rule…]. Posteriormente seguiremos estos pasos:

1)      Seleccionar la opción [Crash]

2)      Configurar a que proceso(s) o aplicación(es) adjuntaremos el depurador mediante alguna de las alternativas que nos proporciona la herramienta (en muchas ocasiones hay varias opciones válidas para conseguir el mismo resultado):

a)      All active IIS/COM+ related processes: Adjuntará el depurador a todos los procesos INETINFO.EXE, W3WP.EXE y DLLHOST.EXE que se ejecuten en la máquina. De esta forma obtendremos datos de cualquier crash que se produzca en un proceso relacionado con IIS.

b)      A specific process: Adjuntará el depurador a un proceso específico (un determinado PID) o a todos los procesos con el mismo nombre de ejecutable (por ejemplo W3WP.EXE), en función de sí seleccionamos la opción This process instance only.

c)      A specific MTS/COM+ application: Adjuntará el depurador al proceso DLLHOST.EXE que aloje la aplicación COM+ que indiquemos.

d)      Web application pool: Adjuntará el depurador al proceso W3WP.EXE que aloje el application pool que indiquemos.

e)      NT Service: Adjuntará el depurador al proceso que aloje al servicio de Windows que indiquemos, por ejemplo SVCHOST.EXE.

3)      En la pantalla de configuración avanzada dejaremos la configuración predeterminada, de forma que no tome ninguna acción cuando se produzcan excepciones de first chance:

4)      Por último debemos indicar el nombre de la regla, la ubicación donde volcará los datos generados y activarla para que empiece a capturar datos. En función del escenario, estos datos pueden ser de gran tamaño por lo que conviene elegir una unidad que no tenga problemas de espacio.

VOLCADOS DE EXCEPCIONES .NET

En muchas ocasiones necesitamos analizar volcados de determinadas excepciones .NET, para examinar el estado de los objetos implicados en el momento de producirse la excepción. A partir de .NET 2.0, el CLR hace una gran labor registrando información sobre las excepciones no manejadas en el log de eventos NT, pero en ocasiones no es suficiente y necesitamos los volcados de memoria. Para configurar una regla de crash de estas características debemos posicionarnos en la pestaña [Rules] y posteriormente pulsar sobre el botón  [Add Rule…]. Posteriormente seguiremos estos pasos:

1)      Seleccionar la opción [Crash]

2)      Configurar a que proceso(s) o aplicación(es) adjuntaremos el depurador mediante alguna de las alternativas que nos proporciona la herramienta. Habitualmente nos adjuntaremos a uno o varios procesos W3WP.EXE mediante alguno de los mecanismo que nos proporciona la herramienta:

a.      All active IIS/COM+ related processes: Adjuntará el depurador a todos los procesos INETINFO.EXE, W3WP.EXE y DLLHOST.EXE que se ejecuten en la máquina. De esta forma obtendremos datos de cualquier crash que se produzca en un proceso relacionado con IIS.

b.      A specific process: Adjuntará el depurador a un proceso específico (un determinado PID) o a todos los procesos con el mismo nombre de ejecutable (por ejemplo W3WP.EXE), en función de sí seleccionamos la opción This process instance only.

c.       A specific MTS/COM+ application: Adjuntará el depurador al proceso DLLHOST.EXE que aloje la aplicación COM+ que indiquemos.

d.      Web application pool: Adjuntará el depurador al proceso W3WP.EXE que aloje el application pool que indiquemos.

e.      NT Service: Adjuntará el depurador al proceso que aloje al servicio de Windows que indiquemos, por ejemplo SVCHOST.EXE.

3)      En la pantalla de configuración avanzada pulsamos sobre el botón [Exceptions] y en la ventana de First Chance Exception Configuration le damos a [Add Exception…]. Esto abre una nueva ventana donde configuraremos la excepción específica que queremos monitorizar. Debemos seleccionar el tipo de excepción adecuado en la columna izquierda CLR (.NET) Exception y posteriormente indicar el tipo de excepción y la acción a tomar. Es importante tener en cuenta que el campo [.NET Exception Type] es case sensitive, por lo que debemos poner el nombre exacto de la excepción con las mayúsculas y minúsculas adecuadas. La acción a realizar cuando se produzca una excepción como la configurada será generar un Full Userdump, y limitaremos esta acción a un máximo de 10 volcados:

4)      Una vez configurada la excepción adecuada, pulsamos [OK] à [Save & Close] à [Next], y finalizamos indicando el nombre de la regla, la ubicación donde volcará los datos generados y activando la regla para que empiece a capturar datos

En una serie de próximos posts, cubriré algunas técnicas para introducirse en el análisis de volcados de memoria.

Happy hacking,

- Daniel Mossberg

En ocasiones, necesitamos capturar trazas de red durante un periodo de tiempo prolongado, por ejemplo para esperar hasta que se produzca un determinado comportamiento aleatorio que pretendemos investigar. Para estos escenarios puede ser útil capturar una traza de red circular, de forma que únicamente se guarden los últimos n MB capturados, y los datos anteriores se vayan desechando automáticamente.

De esta forma, la traza puede estar capturando datos durante días, y en el momento que se produzca el problema, paramos la traza que contendrá el tráfico de red relevante que pretendíamos investigar en un fichero de un tamaño manejable.

Es importante configurar un tamaño de buffer lo suficientemente grande para tener un margen desde que se reproduce el problema hasta que se para la traza, de forma que esta contenga el periodo de tiempo que se pretende investigar. El problema de las trazas circulares es que si se para la traza demasiado tarde, es posible que los datos que se pretendían investigar ya hayan sido desechados.

Network Monitor, permite capturar trazas circulares mediante la utilidad de línea de comandos nmcap.exe. La sintaxis para capturar una traza circular de 200 MB sería la siguiente:

C:\...\Microsoft Network Monitor 3>nmcap.exe /network * /capture /file netTrace.cap:200M

Netmon Command Line Capture (nmcap) 3.3.1641.0

Saving info to:

C:\Program Files\Microsoft Network Monitor 3\netTrace.cap - using circular buffer of size 200.00 MB.

ATTENTION: Conversations Enabled: consumes more memory (see Help for details)

Exit by Ctrl+C

Capturing   | Received: 411 Pending: 0 Saved: 411 Dropped: 0 | Time: 17 seconds.

En el momento que se haya producido el problema, finalizamos la captura presionando Ctrl + C.

Hasta el próximo post,

- Daniel Mossberg

Realizando estos pases resolveréis el problema de consumo de memoria en DbgHost.exe.

Hasta el próximo post.

- Daniel Mossberg

Esta es una problemática relativamente común. Por ejemplo, actualizamos un ensamblado (DLL) de nuestra aplicación ASP.NET, y cuando la probamos vemos que todavía no se han reflejado los cambios y que la aplicación se comporta igual que antes del cambio. ¿Por qué no se reflejan los cambios inmediatamente?

ASP.NET trabaja con application domains para proporcionar aislamiento entre aplicaciones alojadas en un mismo proceso. El application domain contiene todos los datos relacionados con una aplicación en particular, que son (simplificando): todos los ensamblados específicos de la aplicación, un objeto HttpRuntime y un objeto Cache. Un application domain se puede descargar del proceso que lo aloja, pero un ensamblado no se puede descargar del application domain que lo ha cargado.

Por lo tanto, cuando el runtime de .NET (CLR) detecta, por ejemplo, que algún ensamblado de la carpeta ~/bin de la aplicación ha sido modificado, carga un nuevo application domain con la última versión del ensamblado, y el application domain antiguo se descarga del proceso en cuanto haya terminado de servir todas las peticiones en curso.

Cada vez que se reinicia el application domain, todos los ensamblados tienen que volver a cargarse (previamente haciendo el shadow copy), el código vuelve a compilarse por el JIT-compiler, y la cache y las variables de sesión se reinician. El proceso de reinicio del application domain es bastante costoso, por lo que conviene evitar que se produzca cuando la aplicación web tiene mucha carga de usuarios.

ASP.NET utiliza la API Win32 ReadDirectoryChangesW para monitorizar cambios en carpetas y ficheros. Cuando detecta alguno de los siguientes cambios, se reinicia el application domain (esta lista la he sacado directamente del siguiente post de mi compañera Tess):

·         Modificaciones en Web.Config, Machine.Config o Glabal.asax

·         Modificaciones en la carpeta ~/bin o en su contenido

·         La ruta física del directorio virtual es modificada

·         Alguna subcarpeta de la aplicación web es eliminada (sólo en ASP.NET 2.0)

Adicionalmente, los siguientes eventos también provocan un reinicio del application domain:

·         La política CAS (Code Access Security) es modificada.

·         El número de recompilaciones dinámicas¹ de ficheros *.aspx, *.ascx o *.asax excede el límite especificado en la propiedad <compilation numRecompilesBeforeAppRestart="15"/> en el machine.config o web.config  (por defecto este valor es de 15)

¹⁾ Es importante puntualizar que modificar un fichero *.aspx, *.ascx o *.asax también implica una recompilación, dado que en ASP.NET absolutamente todo el código termina siendo compilado, incluso el código “HTML” de la capa de presentación. Las recompilaciones dinámicas, se gestionan de una forma distinta ya que en lugar de reiniciar el application domain directamente, se invalida el ensamblado con la versión antigua del fichero .aspx, y se carga un nuevo ensamblado con la nueva versión.

A la larga, dado que no se pueden descargar ensamblados de un application domain, este comportamiento de ASP.NET supondría que el consumo de memoria aumentaría progresivamente debido a la acumulación de ensamblados invalidados. Por este motivo, ASP.NET reinicia el application domain llegado un número determinado de recompilaciones, para de esta forma poder descargar los ensamblados invalidados.

Por lo tanto, para evitar los problemas asociados a los reinicios de los application domains y a las recompilaciones dinámicas, debemos seguir las siguientes medidas:

a)      Realizar despliegues a producción cuando el servidor tenga la menor carga posible, o mejor incluso sacándolo del balanceo de forma que no atienda peticiones.

b)      Cuando el punto a) no sea posible, podemos añadir / modificar los parámetros waitChangeNotification y maxWaitChangeNotification para minimizar el número de reinicios del application domain. Estos parámetros se pueden configurar en el web.config de la aplicación web en cuestión. Por ejemplo:

<system.web>

  <httpRuntime waitChangeNotification="10" maxWaitChangeNotification="60" />

</system.web>

Este mecanismo funciona de la siguiente manera: en el momento que sobrescribimos un fichero existente dentro de la estructura de carpetas de nuestra aplicación web, un objeto de File Change Notification detecta el cambio y transcurrido el tiempo que hayamos configurado en el campo waitChangeNotification reiniciará el application domain. Si durante este periodo de espera detecta otro cambio adicional, volverá a esperar otra vez el número de segundos que hayamos configurado en waitChangeNotification, y así sucesivamente hasta que se alcance el tiempo de espera que hayamos configurado en maxWaitChangeNotification. Cuando se alcanza el tiempo de espera configurado en maxWaitChangeNotification, el application domain se reinicia al margen de que se sigan detectando cambios.

De esta forma, el application domain no se reinicia hasta que se hayan “terminado de copiar” todos los nuevos ficheros a la carpeta de contenido, evitando así múltiples reinicios con su consiguiente coste. Esta problemática también está descrita en detalle en el post al que hacía referencia antes de mi compañera Tess Ferrandez.

c)      En ocasiones es interesante probar si deshabilitando la “compilación por lotes” mejora el comportamiento. Este cambio ocasiona que no se compile la aplicación entera cuando se carga el application domain sino únicamente las partes relevantes de la aplicación requeridas para atender la primera petición. Por un lado se reduce el retraso inicial para responder a la primera petición, aunque por otro lado, cuando llegue una petición posterior que requiera una parte de la aplicación que no haya sido compilada, esa petición también experimentará un retraso.

Este cambio aplica sobre todo para aplicaciones compuestas por gran cantidad de ensamblados y páginas.

<system.web>

  <compilation batch="false" />

</system.web>

Espero que esta información os sea de utilidad.

- Daniel Mossberg

Este post es la continuación de Cuándo y cómo capturar volcados de memoria en modo Hang

La herramienta Debug Diagnostics Tool se puede descargar desde aquí, tanto la versión de 32-bit como la de 64-bit. En el momento de escribir este post, la herramienta está en la versión 1.1 y está soportada para los siguientes sistemas operativos:

·         Windows 2000 Server

·         Windows Server 2003

·         Windows XP

Es decir, si pretendemos analizar un problema en Windows Server 2008, Windows Server 2008 R2, Windows Vista o Windows 7 es recomendable utilizar otras herramientas, aunque algunas funcionalidades de Debug Diagnostics pueden funcionar en estos sistemas operativos.

Nota

En el caso de los sistemas operativos de 64-bit, es conveniente instalar la versión de DebugDiag en función del proceso que se va a monitorizar. Es decir, si el proceso es de 32-bit, es mejor utilizar la versión de 32-bit de DebugDiag al margen de que Windows sea de 64-bit (de esta forma nos quitamos del medio la capa WOW64 que a veces dificulta la depuración).

DebugDiag nos permite capturar volcados de hang básicamente de tres formas distintas:

Volcado manual de todos los procesos de IIS

Volcado manual de un proceso específico

Regla de hang

VOLCADO MANUAL DE TODOS LOS PROCESOS DE IIS

Podemos generar los volcados manualmente cuando se esté reproduciendo el problema desde el menú [Tools] à [Create IIS/COM+ Hang Dump].

 

Por defecto, los volcados se generarán en la ruta: C:\Program Files\DebugDiag\Logs\Misc

VOLCADO MANUAL DE UN PROCESOS ESPECÍFICO

Podemos generar volcados manualmente de un proceso específico desde la pestaña [Processes] à [Botón derecho sobre el proceso] à [Create Full Userdump]

Al igual que en el anterior caso, los volcados se generan en la ruta: C:\Program Files\DebugDiag\Logs\Misc.

REGLA DE HANG

Las reglas de hang de Debug Diagnostic permiten monitorizar la salud de una aplicación web de forma automatizada, y generar volcados en el momento que la herramienta detecta que la aplicación no respohnde en los tiempos establecidos.

Para configurar una regla de hang debemos posicionarnos en la pestaña [Rules] y posteriormente pulsar sobre el botón  [Add Rule…]. Posteriormente seguiremos estos pasos:

1)      Seleccionar la opción [IIS Hang]

2)      En la siguiente pantalla, seleccionar las URLs que queremos monitorizar con la herramienta. Debemos configurar al menos una URL, pero en algunos escenario puede tener sentido monitorizar varias. El funcionamiento del mecanismo de monitorización es muy sencillo. Se basa en realizar peticiones HTTP a las URLs configuradas, y esperar hasta que una de esas peticiones no sea atendida en el tiempo establecido para alertar al depurador que se está produciendo un hang.

Para cada URL, configuraremos independientemente la propiedad ping interval, que es el intervalo de tiempo entre cada ping a la URL, y la propiedad timeout que es el intervalo de tiempo que vamos a esperar a recibir una respuesta. En el momento que la respuesta al ping exceda el tiempo que hemos especificado en timeout, se generará un volcado automáticamente.

Los valores predeterminados de la herramienta establecen el valor de la propiedad timeout a 120 segundos. Personalmente opino que es un valor muy excesivo, y que en la mayoría de los casos, si una petición HTTP no ha respondido en 30 segundos, se puede confirmar que se está produciendo una contención. Es difícil hacer una recomendación genérica sobre estos parámetros, porque depende mucho de cada aplicación y cada escenario individual. Yo suelo recomendar poner ambos valores a 30, pero al final eso lo tiene que decidir quien conoce la aplicación.

3)      En el siguiente paso, debemos configurar que hará la herramienta cuando detecte que se está produciendo una situación de hang. Para ello debemos pulsar sobre el botón [Add Dump Target] y seleccionar alguna de las siguiente opciones:

a)      All active IIS/COM+ related processes: Generará volcados de todos los procesos INETINFO.EXE, W3WP.EXE y DLLHOST.EXE. Esta opción es interesante cuando no sabemos a priori cual es el proceso que provoca la contención.

b)      Executable: Generará volcados de todos los procesos con el mismo nombre que el proceso que indiquemos, por ejemplo W3WP.EXE.

c)      COM+ application: Generará un volcado del proceso DLLHOST.EXE que aloje la aplicación COM+ que indiquemos.

d)      Web application pool: Generará un volcado de memoria del proceso W3WP.EXE que aloja el application pool que indiquemos.

e)      NT Service: Generará un volcado del proceso que aloje al servicio de Windows que indiquemos, por ejemplo SVCHOST.EXE.

4)      Por último debemos indicar el nombre de la regla y la ubicación donde volcará los datos generados. En función de la circunstancias, estos datos pueden ser de gran tamaño por lo que conviene elegir una unidad que no tenga problemas de espacio.

- Daniel Mossberg

En el contexto de este post, se entiende por hang (yo lo traduciría al castellano como contención) una situación en la que una aplicación responde mucho más despacio de lo normal o deja de responder por completo. Una contención puede ser temporal (pasado un rato la aplicación vuelve a funcionar correctamente) o permanente (lo que se conoce como deadlock), y puede ir asociada a un consumo de CPU elevado o un consumo bajo (o incluso nulo).

Los volcados de memoria en modo hang muestran el estado de la memoria de un proceso en un momento determinado en el tiempo. Por lo tanto, para que la información contenida en el volcado tenga algún valor es imprescindible capturar el volcado en el momento adecuado. Revisemos los distintos escenarios en los que necesitaremos capturar volcados de memoria en modo hang:

Contención y consumo de CPU bajo

Habitualmente, cuando la aplicación no responde ni consume CPU es que está esperando a algo que se ejecuta en un proceso distinto o incluso en un servidor distinto. Por ejemplo, puede estar esperando a obtener respuesta de una llamada RPC, a obtener respuesta de una llamada por sockets, o a que se libere una sección crítica. En ocasiones, como ya adelantaba antes, estas contenciones pueden ser permanentes si esa respuesta nunca llega o la sección crítica nunca se libera (siguiendo con el ejemplo anterior).

Para este tipo de problemas es interesante capturar tres volcados con un intervalo de un minuto entre cada uno (aproximadamente), y cuando sea posible capturar volcados de todos los procesos implicados en la aplicación cuando se esté reproduciendo el problema.

Esto nos permitirá ver cómo evoluciona el proceso con el tiempo (por eso cogemos varios volcados), y además obtendremos datos de todos los procesos implicados dado que a priori no podemos saber en qué proceso se produce la contención.

Las dos herramientas más comunes para capturar estos volcados son Debug Diagnostics y Adplus. En los siguientes posts encontraréis la información detallada sobre cómo generar los volcados:

·         Cómo capturar volcados de hang con Debug Diagnostics Tool

·         Cómo capturar volcados de hang con Adplus (próximamente)

Contención y consumo de CPU elevado

Para este tipo de problemas, al contrario que la categoría anterior, es más evidente cual es el proceso que nos interesa analizar (el que consume CPU). Por lo tanto, la forma de capturar los volcados es ligeramente distinta.

Para este tipo de problemas es interesante capturar tres volcados con un intervalo de un minuto entre cada uno (aproximadamente) del proceso específico con elevado consumo de CPU cuando se esté reproduciendo el problema.

Al igual que en el anterior escenario, podemos utilizar las herramientas Debug Diagnostics y Adplus para capturar este tipo de volcados. Adicionalmente, existe una herramienta llamada ProcDump diseñada especialmente para generar volcados cuando un proceso supere un determinado umbral de consumo de CPU. En los siguientes posts encontraréis la información detallada sobre cómo generar los volcados:

·         Cómo capturar volcados de hang con Debug Diagnostics Tool

·         Cómo capturar volcados de hang con Adplus (próximamente)

·         Cómo capturar volcados de hang con ProcDump (próximamente)

Próximamente veremos cuándo y cómo capturar volcados de memoria en modo crash.

Hasta pronto

- Daniel Mossberg

Imaginemos el siguiente escenario: Tenéis una aplicación web que requiere o acepta certificados de cliente, y que mediante un formulario HTML hace POST para subir ficheros al servidor. En algunas ocasiones, cuando los ficheros superan un determinado tamaño, la petición falla y en los logs de IIS vemos un error HTTP 413 – Request entity too large.

Este es un comportamiento conocido cuando están habilitados certificados de cliente en combinación con que se realiza un petición HTTP de gran tamaño (por ejemplo un POST HTTP adjuntando ficheros). El motivo es que IIS lee los primeros n bytes de la petición (ahora veremos qué determina esa n), asumiendo que deberían haber llegado todos los encabezados de la petición (HTTP headers), pero no necesariamente todos los datos asociados (entity body) de la petición.

Esto habitualmente no supone un problema, pero en nuestro escenario en particular, IIS examina los encabezados de la petición, encuentra que la página requiere certificados de cliente y que por lo tanto necesita renegociar la conexión SSL. Desafortunadamente, el cliente (IE) no puede renegociar la conexión porqué está esperando a poder enviar el resto de datos del entity body a IIS. Para evitar que se produzca un deadlock (IIS esperando a poder renegociar la conexión SSL e IE esperando a poder mandar el entity body), IIS devuelve un error HTTP 413 y cierra la conexión.

Para evitar que se produzca este problema tenemos dos opciones:

1)      Para que la renegociación de la conexión se pueda llevar a cabo, el entity body completo tiene que estar “precargado” utilizando SSL Preload. SSL Preload utiliza la propiedad de la metabase UploadReadAheadSize para determinar el tamaño del buffer en el que almacenará la petición (los n bytes a los que hacía referencia antes). Por lo tanto si el tamaño de este buffer es inferior al tamaño total de la petición HTTP (lo que incluye los encabezados HTTP y el entity body), IIS devuelve el error HTTP 413.

El tamaño predeterminado de ese buffer son 48k, lo cual es un tamaño insuficiente en muchas ocasiones, pero que fue establecido así para evitar ataques de denegación de servicio subiendo ficheros “basura” de gran tamaño.

La sintaxis para aumentar dicho buffer es la siguiente, y se puede especificar de forma granular a nivel de directorio virtual:

C:\inetpub\adminscripts>cscript adsutil.vbs set w3svc/1/root/myApp/uploadreadaheadsize 20000000

Microsoft (R) Windows Script Host Version 5.6

Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

uploadreadaheadsize             : (INTEGER) 20000000

El número indicado es el número de bytes, por lo que 20.000.000 bytes (como en el ejemplo) serían aproximadamente unas 19,1MB.

2)      La otra alternativa es habilitar la clave de la metabase SSLAlwaysNegoClientCert de forma que forcemos a que por cada nueva conexión SSL que se establezca, el servidor negociará inmediatamente el certificado de cliente. De esta forman se previene la renegociación, lo cual supone una ganancia de rendimiento en sí misma, y además evita el problema asociado a las peticiones con entity body de gran tamaño. La sintaxis para habilitar esta clave es:

C:\inetpub\adminscripts>cscript adsutil.vbs set w3svc/1/SSLAlwaysNegoClientCert true

Microsoft (R) Windows Script Host Version 5.6

Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

SSLAlwaysNegoClientCert         : (BOOLEAN) True

INFORMACIÓN ADICIONAL

Client cannot renegotiate request and returns an HTTP 413 error (IIS 6.0)

http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/7e0d74d3-ca01-4d36-8ac7-6b2ca03fd383.mspx?mfr=true

 Happy hacking

- Daniel Mossberg

Los ordenadores procesan texto utilizando tablas de codificación para convertir secuencias de bits en caracteres alfanuméricos y viceversa. Cuando desarrollamos aplicaciones, y muy especialmente aplicaciones distribuidas o aplicaciones web, tenemos que tener en cuenta la codificación (o enconding) con la que “ciframos” y “desciframos” los mensajes, dado que si utilizamos codificaciones distintas el mensaje resultante puede resultar incorrecto.

Antes de meternos de lleno en las consideraciones específicas de desarrollo, revisemos brevemente los encodings más comunes que puede ser interesante conocer.

ASCII

ASCII (American Standard Code for Information Interchange) se desarrolló en los años 60 y es una tabla de codificación que utiliza 7 bits para representar 128 caracteres, de los cuales 94 son caracteres legibles y 33 son caracteres de control y el espacio que se considera un carácter invisible. Esta codificación no sirve para representar la ‘ñ’ o los acentos, y hoy en día en muchos contextos se considera obsoleta.

Windows-1252 (Western European)

Históricamente era la codificación predeterminada en muchos contextos de Windows. Es una codificación de 8 bits para representar 256 caracteres, e incluye la mayoría de los caracteres utilizados en los alfabetos de Europa occidental.

ISO-8859-1 (Latin 1)

Esta codificación ISO de 8 bits fue publicada en 1985, y es un subconjunto de la codificación Windows-1252 compuesto por 191 caracteres. Es informalmente conocida como Latin 1.

ISO-8859-15 (Latin 9)

En 1999 se publicó esta codificación como una actualización de ISO-8859-1 para corregir algunas de sus limitaciones. Sigue utilizando 8 bits para representar cada carácter, y entre otros cambios se añadieron algunos caracteres del alfabeto fines (Š y Ž), y el símbolo del euro (€). Para poder acomodar estos cambios, se tuvieron que eliminar algunos otros caracteres de uso poco frecuente, entre los cuales se encontraban: ¤, ¦, ¨, ´, ¼, ½, y ¾.

UTF-8

UTF-8 (8-bit Unicode Transformation Format) es una codificación de longitud variable entre 1 y 4 bytes. La representación de un byte (8 bits) de UTF-8 se reserva exclusivamente a los 128 caracteres de la tabla ASCII lo cual lo hace compatible hacia atrás. Los siguientes 1920 caracteres de UTF-8 requieren dos bytes para ser codificados, entre los cuales se incluyen el alfabeto latino, griego, cirílico, hebreo, árabe, sirio, etc.

Por lo tanto, la moraleja de este breve resumen, es que aunque tanto Windows-1252 y UTF-8 sean capaces de representar el carácter ‘Ñ’, lo hacen de forma distinta. De hecho, para ser más precisos lo hacen así:  

Por lo tanto, queda claro que si codificamos un texto utilizando Windows-1252 y posteriormente lo decodificamos los bytes resultantes utilizando UTF-8, lo que inicialmente era un ‘Ñ’ va a pasar a ser cualquier otra cosa excepto una ‘Ñ’ al decodificarlo.

Ahora que ya tenemos más clara la problemática, os detallo algunas consideraciones concretas para ASP.NET:

1)      Dado que ASP.NET nos permite configurar la codificación utilizada para generar las respuestas, y la codificación predeterminada para decodificar las peticiones, es importante asegurarse de que se utiliza la misma codificación en la otra parte implicada, el cliente. Esta es la configuración predeterminada de ASP.NET:

<configuration>
  <system.web>
    <globalization

      requestEncoding="utf-8"

      responseEncoding="utf-8" />
  </system.web>
</configuration>

2)      En una respuesta HTTP podemos especificar la codificación del contenido en dos sitios. En el encabezado HTTP Content-Type o en un meta tag dentro del propio documento HTML. En caso de conflicto entre ambos (como en el ejemplo), tiene preferencia la configuración especificada en el encabezado HTTP.

HTTP/1.1 200 OK

Date: Tue, 1 Dec 2009 10:23:34 GMT

Server: Microsoft-IIS/6.0

Content-Length: 48

Content-Type: text/html; charset=utf-8

Cache-control: private

<html xmlns="http://www.w3.org/1999/xhtml">

  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
  </head>
  <body>
    …
  </body>

</html>

Un problema frecuente es enviar respuestas HTTP sin especificar en ningún sitio la codificación utilizada. Cuando se da el caso, el cliente que recibe la respuesta tiene que determinar la codificación que utilizará para decodificar el contenido. Habitualmente, es tan sencillo como que el cliente utilizará la codificación predeterminada del sistema operativo, por lo que existe un elevado riesgo de que en algún cliente con una determinada configuración se muestre incorrectamente.

3)      Otro problema con el que me he encontrado en varias ocasiones es relativo al dialogo de descarga de Internet Explorer. Cuando generamos una respuesta HTTP dinamicamente desde ASP.NET para enviar un fichero, podemos encontrarnos con que el dialogo de descarga muestra el nombre del fichero con caracteres incorrectos:

Este problema se debe a que ASP.NET (1.1 y 2.0) por defecto codifican los encabezados HTTP con UTF-8. En ASP.NET 1.1 es necesario instalar la siguiente actualización para poder especificar la codificación de los encabezados:

FIX: The response header will always be encoded as UTF-8 when you use the Response.Addheader method in ASP.NET

http://support.microsoft.com/default.aspx?scid=kb;EN-US;895262

Una vez instalada la actualización, podemos especificarla en el web.config de la aplicación:

<globalization responseHeaderEncoding="Windows-1252"/>

En ASP.NET 2.0 se puede cambiar la codificación de los encabezados HTTP programáticamente además de mediante la opción del web.config (igual que en ASP.NET 1.1):

protected void Page_Load(object sender, EventArgs e)

{

    //Leemos el fichero DOCX y lo almacenamos en un array de bytes

    string FileName = "Diseño gráfico.docx";

    string FilePath = MapPath(FileName);

    byte[] FileBytes = File.ReadAllBytes(FilePath);       

    //ASP.NET codifica los encabezados HTTP con 'utf-8' de forma

    //predeterminada. Especificamos que utilice la codificación 

    //ANSI predeterminada del OS, que en mi caso es 'Windows-1252'

    Response.HeaderEncoding = System.Text.Encoding.Default;   

    //Establecemos el MIME type de la respuesta y añadimos el

    //encabezado HTTP 'Content-Disposition'           

    Response.ContentType = "application/docx; charset=utf-8";

    Response.AddHeader("Content-Disposition", "Inline; filename=" +

        FileName);

    //Envíamos el fichero en formato binario

    Response.BinaryWrite(FileBytes);           

}

Hasta el próximo post

- Daniel Mossberg

La mayoría de los casos de soporte que nos abren para diagnosticar problemas al conectarse por HTTPS a un sitio web, suelen resolverse realizando alguno de los pasos descritos a continuación. Partimos de la premisa de que podemos acceder correctamente por HTTP para acotar el escenario a un problema al establecer la conexión HTTPS.

1)      Lo primero que suelo comprobar es que el certificado es válido y está emitido con el propósito adecuado.

a)      Para ello debemos examinar las propiedades del certificado de servidor, y en la pestaña General verificar que el certificado es válido y tiene una clave privada.

b)      Comprobar también en la pestaña Details que la propiedad Enhanced Key Usage (o Uso Mejorado de Clave) incluye el valor Server Authentication (1.3.6.1.5.5.7.3.1).

c)      Por último vayamos a la pestaña Certification Path y verifiquemos que todos los certificados en la cadena de certificación tienen el estado OK.



Las condiciones descritas en los pasos a, b y c constituyen el mínimo imprescindible para que se pueda establecer una conexión SSL, pero el hecho de que todo esté correcto no descarta por completo que el problema se encuentre en el certificado. Más adelante realizaremos pruebas adicionales para descartar problemas de integridad con el certificado. 

2)      Comprobar si existe un conflicto con alguna otra aplicación que esté escuchando por el puerto 443 (o el que aplique en cada caso). Si este es el caso, es posible que veamos el siguiente evento registrado en los logs de eventos NT:

Event Type:          Error

Event Source:        W3SVC

Event Category:      None

Event ID:            1114

Description:         One of the IP/Port combinations for site '1' has already been configured to be used by another program. The other program's SSL configuration will be used.

Para diagnosticar esta situación, inicialmente ejecutaremos el siguiente comando:

C:\WINDOWS\system32>netstat -noa

Si todo es correcto, sólo debería haber una aplicación escuchando por el puerto 443, y el resultado debería ser algo parecido a esto (el PID 4 siempre equivale al proceso System):

Active Connections

  Proto  Local Address   Foreign Address  State       PID

  TCP    0.0.0.0:80      0.0.0.0:0        LISTENING   4

  TCP    0.0.0.0:135     0.0.0.0:0        LISTENING   688

  TCP    0.0.0.0:443     0.0.0.0:0        LISTENING   4

  TCP    0.0.0.0:445     0.0.0.0:0        LISTENING   4

Si nos surgen dudas sobre si realmente es IIS (o el proceso System) el que está escuchando por el puerto 443, podéis utilizar la herramienta tasklist.exe o simplemente Task Manager para confirmarlo. Si el puerto estuviera en uso por otra aplicación, habría que determinar qué aplicación usa el puerto y para qué. La forma de verificar si este es realmente el problema sería probar a configurar SSL en un puerto distinto y verificar si funciona.

Si netstat no arroja luz sobre el conflicto de puertos, pero no obstante vemos el evento mencionado anteriormente (Event ID 1114) en los logs de eventos, ejecutaremos el siguiente comando para sacar un listado de los certificados SSL asociados a IIS:

C:\Program Files\Support Tools>httpcfg query ssl

Cuando revisemos la lista debemos buscar alguna entrada en la que el campo de Hash y CertStoreName están vacíos o nulos, y el Guid está todo a ceros. Este es indicativo de un problema.

IP                      : 0.0.0.0:443

Hash                    :

Guid                    : {00000000-0000-0000-0000-000000000000}

CertStoreName           : (null)

CertCheckMode           : 0

RevocationFreshnessTime : 0

UrlRetrievalTimeout     : 0

SslCtlIdentifier        : (null)

SslCtlStoreName         : (null)

Flags                   : 0

Para solventar este problema, debemos eliminar el binding entre IIS y el certificado ejecutando el siguiente comando (la sintaxis genérica es: httpcfg delete ssl -i ip:puerto):

C:\Program Files\Support Tools>httpcfg delete ssl -i 0.0.0.0:443

Y posteriormente volver a configurar el certificado SSL desde INETMGR.EXE. Si volvemos a listar los certificados SSL con httpcfg.exe el resultado ahora debería ser algo parecido a esto:

IP                      : 0.0.0.0:443

Hash                    : d753a06831d416db4bf2 9f5 aa33ae714dfba5d

Guid                    : {4dc3e181-e14b-4a21-b022-59fc669b0914}

CertStoreName           : MY

CertCheckMode           : 0

RevocationFreshnessTime : 0

UrlRetrievalTimeout     : 0

SslCtlIdentifier        :

SslCtlStoreName         :

Flags                   : 0

3)      Crear un certificado de pruebas con SelfSSL.exe para verificar que el problema no es del certificado. Esta herramienta se puede descargar como parte del Resource Kit de IIS 6.0. La herramienta genera un certificado de pruebas automáticamente y lo instala para un sitio web determinado. La sintaxis es la siguiente:

selfssl.exe /N:CN=[Nombre Cert.] /V:[Días Validez Cert.] /S:[ID Sitio Web] /P:[Puerto SSL]

Por ejemplo, para nuestro sitio web de anteriores ejemplos ejecutaríamos el siguiente comando y posteriormente volveríamos a probar si podemos establecer la conexión HTTPS:

C:\Program Files\IIS Resources\SelfSSL>selfssl.exe /N:CN=mywebsite.microsoft.com /V:365 /S:1 /P:443

Microsoft (R) SelfSSL Version 1.0

Copyright (C) 2003 Microsoft Corporation. All rights reserved.

Do you want to replace the SSL settings for site 1 (Y/N)?Y

The self-signed certificate was successfully assigned to site 1.

4)      Por último reinstalaremos el certificado seleccionando manualmente el almacén de certificados en el que se instala. Es decir, al instalar el certificado, no seleccionar la opción de Automatically select the certificate store based on the type of certificate, sino hacerlo manualmente marcando la casilla Show physical stores y seleccionando el almacén deseado desde aquí.



De esta forma descartaremos que tenemos el problema descrito en el post Certificate has private key but we get "the keyset does not exist" error.

Si llegados a este punto seguís sin poder establecer una conexión HTTPS contra vuestro servidor, será un buen momento para abrir un caso de soporte con Microsoft.

Espero que os haya sido de utilidad.

- Daniel Mossberg