Classe System.Net.HttpListener

Observação

Este artigo fornece observações complementares à documentação de referência para esta API.

Usando a HttpListener classe, você pode criar um ouvinte de protocolo HTTP simples que responde a solicitações HTTP. O ouvinte fica ativo durante o tempo de vida do objeto HttpListener e é executado no seu aplicativo com suas permissões.

Para utilizar HttpListener, crie uma nova instância da classe usando o construtor HttpListener e utilize a propriedade Prefixes para aceder à coleção que contém as cadeias de caracteres que especificam quais prefixos de URI (Identificador Uniforme de Recursos) o HttpListener deve processar.

Uma cadeia de caracteres de prefixo URI é composta por um esquema (http ou https), um host, uma porta opcional e um caminho opcional. Um exemplo de uma cadeia de caracteres de prefixo completa é http://www.contoso.com:8080/customerData/. Os prefixos devem terminar numa barra para a frente ("/"). O HttpListener objeto com o prefixo que mais se aproxima de um URI solicitado responde à solicitação. Vários HttpListener objetos não podem adicionar o mesmo prefixo, uma Win32Exception exceção é lançada se um HttpListener adiciona um prefixo que já está em uso.

Quando uma porta é especificada, o elemento host pode ser substituído por "*" para indicar que aceita pedidos enviados para a porta se o URI solicitado não corresponder a nenhum outro prefixo. Por exemplo, para receber todas as solicitações enviadas para a porta 8080 quando o URI solicitado não é tratado por nenhum HttpListener, o prefixo é http://*:8080/. Da mesma forma, para especificar que o HttpListener aceita todas as solicitações enviadas para uma porta, substitua o elemento host pelo caractere "+". Por exemplo, https://+:8080. Os caracteres "*" e "+" podem estar presentes em prefixos que incluem caminhos.

Subdomínios wildcard são suportados em prefixos URI geridos por um objeto HttpListener. Para especificar um subdomínio com curinga, use o caractere "*" como parte do nome do host em um prefixo de URI. Por exemplo, http://*.foo.com/. Passe isso como o argumento para o Add método.

Advertência

Ligações curinga de nível superior (http://*:8080/ e http://+:8080) não devem ser usadas. As associações wildcard de nível superior podem abrir o seu aplicativo para vulnerabilidades de segurança. Isso aplica-se tanto a curingas fortes como a fracos. Utilize nomes de host explícitos em vez de curingas. A vinculação de wildcard de subdomínio (por exemplo, *.mysub.com) não apresenta este risco de segurança caso tenha controle sobre todo o domínio pai (ao contrário de *.com, que é vulnerável). Consulte rfc7230 section-5.4 para obter mais informações.

Para começar a escutar solicitações de clientes, adicione os prefixos URI à coleção e chame o Start método. HttpListener oferece modelos síncronos e assíncronos para processar solicitações de clientes. As solicitações e suas respostas associadas são acessadas usando o objeto HttpListenerContext retornado pelo método GetContext ou pelas suas contrapartes assíncronas, os métodos BeginGetContext e EndGetContext.

O modelo síncrono é apropriado se seu aplicativo deve bloquear enquanto aguarda uma solicitação do cliente e se você deseja processar apenas uma solicitação de cada vez. Usando o modelo síncrono, chame o GetContext método, que aguarda que um cliente envie uma solicitação. O método retorna um HttpListenerContext objeto para você para processamento quando um ocorre.

No modelo assíncrono mais complexo, seu aplicativo não bloqueia enquanto aguarda solicitações e cada solicitação é processada em seu próprio thread de execução. Use o BeginGetContext método para especificar um método definido pelo aplicativo a ser chamado para cada solicitação de entrada. Dentro desse método, chame o EndGetContext método para obter a solicitação, processá-la e responder.

Em ambos os modelos, as solicitações de entrada são acessadas usando a HttpListenerContext.Request propriedade e são representadas por HttpListenerRequest objetos. Da mesma forma, as respostas são acessadas usando a HttpListenerContext.Response propriedade e são representadas por HttpListenerResponse objetos. Esses objetos compartilham algumas funcionalidades com os HttpWebRequest e os HttpWebResponse, mas os últimos objetos não podem ser usados em conjunto com HttpListener porque implementam comportamentos de cliente, não de servidor.

Um HttpListener pode exigir autenticação de cliente. Você pode especificar um esquema específico a ser usado para autenticação ou pode especificar um delegado que determine o esquema a ser usado. Você deve exigir alguma forma de autenticação para obter informações sobre a identidade do cliente. Para obter informações adicionais, consulte as propriedades User, AuthenticationSchemes e AuthenticationSchemeSelectorDelegate.

Observação

Se você criar um HttpListener usando https, deverá selecionar um Certificado de Servidor para esse ouvinte. Caso contrário, as solicitações feitas para esta HttpListener falharão devido a um fechamento inesperado da conexão.

Observação

Você pode configurar Certificados de Servidor e outras opções de ouvinte usando o Shell de Rede (netsh.exe). Consulte Network Shell (Netsh) para obter mais detalhes. O executável começou a ser enviado com o Windows Server 2008 e o Windows Vista.

Observação

Se você especificar vários esquemas de autenticação para o HttpListener, o ouvinte desafiará os clientes na seguinte ordem: Negotiate, NTLM, Digeste .Basic

HTTP.sys

A classe HttpListener é construída sobre HTTP.sys, que é o ouvinte em modo kernel que lida com todo o tráfego HTTP para Windows. HTTP.sys Fornece gerenciamento de conexão, limitação de largura de banda e registro em log do servidor Web. Use a ferramenta HttpCfg.exe para adicionar certificados SSL.

A partir do .NET 11, a implementação do Windows HTTP.sysHttpListener suporta a ativação de buffering de resposta ao nível do kernel. Quando ativado, os dados de resposta são armazenados em buffer pelo HTTP.sys antes de serem enviados para o cliente, o que pode melhorar a taxa de transferência para ligações de alta latência. Isto pode ser ativado chamando o AppContext.SetSwitch método da seguinte forma:

AppContext.SetSwitch("System.Net.HttpListener.EnableKernelResponseBuffering", true);