Los que llevamos muchos años programando con ASP.NET/ASP.NET Core y todos los frameworks que han ido surgiendo en su ecosistema, estamos familiarizados con el concepto de "contexto HTTP".

Materializado en forma de objeto de tipo HttpContext, el contexto HTTP es una de las piezas fundamentales de la infraestructura de ASP.NET Core, y nos permite acceder a información sobre la petición HTTP que se está procesando, como los encabezados, el cuerpo de la petición, las cookies, etc., así como base para la generación de la propia respuesta a través de su propiedad Response. En muchos escenarios, se trata de un recurso imprescindible para procesar la petición de la forma adecuada, por lo que estamos acostumbrados a usarlo cuando es conveniente.

Sin embargo, cuando saltamos a Blazor, pronto nos llama la atención que HttpContext no está disponible. Y si lo pensamos, esto tiene bastante sentido en los dos modos de renderización clásicos:

• En Blazor WebAssembly, dado que el código .NET se ejecuta directamente en el cliente, no existen peticiones que procesar y, por tanto, no existe HttpContext. Se trata de una abstracción que sólo existe en el backend.

• En Blazor Server, aunque el código se está ejecutando en el servidor, tampoco tenemos disponible HttpContext porque realmente no existen peticiones: el lado cliente y servidor se comunican mediante un canal websockets implementado con SignalR, que es por donde viajan ascendentemente las acciones realizadas por el usuario y descendentemente las actualizaciones del DOM de la página.

Con la llegada de Blazor 8, ha tomado relevancia el nuevo modo de renderizado, llamado Server-Side Rendering (SSR) o renderización en el lado servidor, que ya vimos por aquí hace algún tiempo.

Como ya sabemos, el funcionamiento de Blazor SSR es similar al de otros frameworks de backend puros, como MVC o Razor Pages: el servidor recibe la petición, la procesa y genera una respuesta HTML que se envía al cliente. En este escenario, durante el proceso del componente Blazor sí existe un contexto HTTP.

En estos casos, el framework introduce en la cascada de parámetros un objeto de tipo HttpContext que podemos recuperar fácilmente desde cualquier componente usando el atributo [CascadingParameter] sobre una propiedad pública de este tipo, por ejemplo así:

@code {
    [CascadingParameter]
    private HttpContext? HttpContext { get; set; }
}

Simplemente con esto, ya podríamos usar el objeto HttpContext para acceder a la información de la petición, o incluso modificar la respuesta. En el siguiente bloque de código podemos ver un ejemplo simple, donde mostramos el contenido del encabezado Host de la petición y modificamos el código de estado de la respuesta:

@page "/Test"

Host: @HttpContext.Request.Host

@code
{
    [CascadingParameter]
    private HttpContext? HttpContext { get; set; }

    protected override void OnInitialized()
    {
        HttpContext.Response.StatusCode = 210;
    }
}

Eso sí, tened en cuenta que, dado que HttpContext es una abstracción sólo válida en el lado servidor, no podremos usarla en el proyecto cliente (<MiProyecto>.Client) de la Blazor Web App, puesto que sus componentes se ejecutan en el navegador y allí no existe el contexto HTTP. De hecho, según indican en la documentación oficial, sólo deberíamos usarla en el componente raíz (normalmente App.razor).

Si desde el lado cliente quisiéramos acceder a datos presentes en el contexto, como encabezados, cookies HttpOnly o similares, tendríamos que buscar la forma de obtener esos valores desde el servidor y hacerlos llegar al lado cliente. Publicaré un post futuro donde podamos ver un ejemplo de esto.

Publicado en Variable not found.