Translate this page now :



»Programação
»Programação.NET
»Banco de Dados
»Webdesign
»Office
» Certificações Microsoft 4
»Treinamentos4
»Programação 4
»Webdesign«
»Office & User Tips«
»Grupos de Usuários
»Células Acadêmicas«
intcontpiada : 118
Os 3 Porquinhos
Você já está cadastrado e participa do grupo de usuários de sua cidade ? Se não, comente o porque.
 
 
Faça um pequeno teste com 10 questões de VB
.:.
Teste seus conhecimentos em Visual Basic, SQL Server e ASP 3.0 com nossas provas on-line
.:.
Aprimore seus conhecimentos em programação com nosso treinamento on-line de lógica de programação
.:.
Veja nosso calendário de treinamentos
Gostou da Página?
Então

para um amigo!
 





Por Dennes Torres
dennes@bufaloinfo.com.br
Dennes Torres possui as certificações MCAD, MCSD,MCSE, MCDBA e MCT. Atualmente atua Como diretor da Búfalo Informática, líder do grupo de usuários DevASPNet no Rio de Janeiro e membro da liderança dos grupos getWindows e devSQL, também do Rio de Janeiro, podendo sempre ser encontrado na lista de discussão do grupo DevASPNet (devaspnet-subscribe@yahoogrupos.com.br) bem como nas reuniões do grupo. Mantém dois blogs em http://cidadaocarioca.blogspot.com

Entendendo a Web e o (ainda novo) HTTP

Pesquisa personalizada
Pesquisar Dicas:







Com tecnologias modernas como o ASP.NET, o desenvolvedor "perdeu" a obrigação de conhecer os detalhes de protocolo do http.

"Perdeu" entre aspas mesmo, pois o conhecimento do HTTP e das características básicas de execução no servidor web continua importante como sempre. Então vamos, neste artigo, analisar essas características e ver de que forma influenciam o processo de execução de uma página web.O protocolo HTTP

O protocolo HTTP foi construido com características de rede voltadas ao funcionamento da web. Destas, a que mais se destaca é o fato de ser um protocolo que não mantém conexão com o servidor.

Isso significa que o protocolo HTTP apenas se conecta ao servidor quando o usuário faz um pedido através do browser (por exemplo). Neste momento, o protocolo se conecta ao servidor, pega os arquivos que o usuário solicitou e se desconecta do servidor. Isso se repete a cada pedido do usuário, mantendo o usuário desconectado do servidor.

Por que isso é feito ?

Imagine o usuário chegando em casa e acessando a web a noite. Ele entra em um site. O filho começa a chamar sua atenção e interrompe-lo. A esposa o chama para jantar, enquanto isso o browser encontra-se aberto exibindo o site que foi chamado. O usuário então começa a ver TV enquanto janta, se distrai com um filme, dorme na poltrona enquanto o browser dorme aberto no micro.Vocês já imaginaram se durante todo esse tempo a conexão de rede com o servidor web estivesse aberta desnecessariamente ? Pois é, os criadores do HTTP imaginaram, e o criaram como um protocolo que não mantém a conexão.

Quando o usuário faz o pedido de uma página, esse pedido normalmente envolve não apenas um, mas diversos arquivos (imagens, javascript, etc.). Por isso o IIS possui a configuração chamada Keep Alive, que mantém a conexão ativa enquanto os vários arquivos estiverem sendo transferidos, ao invés de exigir a abertura de uma conexão distinta para cada arquivo.

O prejuizo para o desenvolvimento

Aplicações não tem o hábito de estarem desconectadas do usuário. Em uma situação destas a aplicação não conseguiria identificar o caminho que o usuário está realizando dentro do site, dificultando muito seu funcionamento (como chegar em uma cesta de compras se não consegue-se saber qual produto o usuário pediu ?).

Tentar identificar o usuário pelo IP não funciona, pois o usuário pode estar atras de um proxy/firewall e consequentemente podem existir inúmeros usuários acessando o site com o mesmo endereço IP. Então como manter a navegação na aplicação de forma coesa para cada usuário que esteja acessando a aplicação ?

O ambiente de Sessão

No momento em que o usuário faz sua primeira requisição ao servidor, este cria uma área de memória vinculada ao usuário. A cada nova requisição, o servidor identifica o usuário e mantém o usuário vinculado com a mesma área de memória, chamada área de sessão. Isso permite que guardemos valores neste espaço de memória e os valores que guardarmos no ambiente de sessão do servidor irão estar presentes, acompanhando o usuário, durante toda a sua navegação pelo site.Ok, mas se eu afirmei há pouco que não era possível identificar o usuário entre as suas conexões, como é que o servidor consegue fazer essa identificação para manter o usuário vinculado a um mesmo espaço de memória ?

No momento do primeiro acesso do usuário ao servidor este cria um código de identificação do usuário, chamado de código de sessão. O código de sessão (ou ID de sessão como as vezes também é chamado) é enviado para a máquina do usuário através do protocolo HTTP. A cada chamada que o usuário faz ao servidor o browser do usuário mostra este ID para o servidor, que ao identificar o ID como uma área de sessão ainda válida vincula o usuário com a sua devida área de sessão.

Cookies

Este ID que é enviado do servidor para o client é enviado na forma de um cookie. Um cookie básicamente é uma informação na forma de um par (nome e valor) enviada para o client através do protocolo http. O protocolo HTTP não determina a forma como o cookie deve ser mantido na máquina do usuário, apenas envia a informação. É o browser do usuário que determina a forma como o cookie será mantido.Existem 2 tipos de cookie : Temporário e permanente. Os cookies temporários apenas são mantidos na memória do browser (o processo de execução do browser), sendo eliminados quando o browser se fecha. Já o cookie permanente é realmente gravado em disco, sendo que a forma como é gravado é de total responsabilidade do browser.O fato do HTTP não poder determinar o local de gravação do cookie garante que não é possível para o servidor invadir a máquina do usuário através dos cookies, o que eventualmente é uma lenda mantida por usuários da web.A diferença entre o cookie permanente e o cookie temporário é a presença de uma data de expiração no cookie permanente. Quando o servidor envia para a máquina do usuário uma data de expiração junto com o cookie o browser entende que deve manter o cookie até aquela data e por isso o grava como cookie permanente. Quando não existe data de expiração o cookie é mantido apenas como cookie temporário.Assim sendo, ID de sessão é enviado para a máquina do usuário na forma de um cookie temporário, passando a ser um dos cookies temporários que acompanhará a navegação do usuário, tendo nós a possibilidade de criarmos, pela aplicação, quantos cookies temporários ou permanentes se fizerem necessários para a aplicação.Todos os cookies gerados por um determinado site passam a trafegar no cabeçalho do protocolo HTTP em todas as requisições realizadas pelo site. Por isso o site tem sempre os cookies a disposição (quando a aplicação lê o seu valor, não é feita uma comunicação, o valor já está acessível ao servidor). O browser identifica o site ao qual o cookie pertence porque o cookie é gravado junto com a URL que o gerou. Assim sendo um outro site qualquer simplesmente não tem como fazer a leitura de todos os cookies do usuário, roubando informações.Roubo de InformaçõesO roubo de informações dos cookies poderia acontecer de 3 formas :

Acesso direto a máquina do usuário

Isso pode significar acesso físico do hacker na máquina do usuário, ou que o usuário tenha instalado uma aplicação maliciosa fornecida pelo hacker, qualquer das duas opções.

Em ambos os casos o hacker pode copiar o arquivo que contém os cookies de determinado site

Script Injection

Isso ocorre quando o hacker, através do próprio site, cadastra alguma informação e, ao invés de inserir dados, insere códigos javascript.Os códigos javascript, quando colocados em determinados pontos, acabarão sendo processados na máquina do usuário. Como estão dentro da página do domínio do site, terão permissão de ler os cookies deste site.Para evitar isso foi criada a opção de gerar cookies do tipo HttpOnly, cookies que apenas possam ser lidos no servidor e não via javascript

Essa possibilidade de invasão é causada por um erro de programação do site

Sniffer

Quando o hacker, utilizando-se de programas de manipulação dos protocolos de rede, intercepta a troca de mensagens entre o usuário e o servidor, capturando os valores dos cookies.Isso ocorre quando o hacker consegue comprometer ou a rede do usuário, ou a rede do site ou alguma rede no meio do caminho por onde o pacote de rede irá passar.Esse tipo de invasão é evitado utilizando-se a criptografia na comunicação entre a máquina do usuário e o servidor, o famoso HTTPS que faz aparecer um cadeado na barra de status do browser.

Como podem observar, o HTTPS apenas evita este terceiro tipo de invasão, os dois tipos anteriores não são afetados pelo HTTPS, podendo ainda ocorrer.

Cookie, HTTP e Sessão

Como o HTTP não possui conexão, o usuário pode trocar de site ou fechar o browser e em momento algum o servidor saberá disso. O servidor é, portanto, um completo desinformado, sem saber se o usuário, ao fechar uma conexão HTTP, irá voltar ou se está indo embora de vez.Assim sendo, a sessão é encerrada apenas quando a aplicação pede explicitamente (uma espécie de logOff), ou quando ocorre um timeout de sessão. O tempo de timeout de sessão é determinado no servidor web e normalmente o tempo utilizado é de 20 minutos, alguns sites, como bancos, reduzem consideravelmente este tempo.Este tempo de timeout determina o tempo em que, caso o usuário não faça nenhum novo acesso ao servidor com o mesmo cookie de sessão, a sessão será retirada da memória do servidor.Desta forma, após o usuário fechar o browser ou mudar de site, a sessão ainda ficará ativa na memória do servidor por mais 20 minutos (ou o tempo com o qual o timeout estiver configurado). Caso o usuário tenha trocado de site e retorne ao site original antes do encerramento do tempo de timeout, suas informações ainda estarão armazenadas na sessão do servidor.Tentativas de obter uma notificação imediata por parte da máquina do usuário quando este estiver saindo do site dependem de programação na própria aplicação (no caso, utilizando JavaScript), porém não fornecem um resultado 100% garantido.

O cookie de sessão, como citado anteriormente, é mantido no processo do browser na máquina do usuário. Isso cria duas situações interessantes : Se o usuário abrir duas vezes o browser, em processos isolados, cada browser poderá estar acessando o site com uma sessão diferente, mantendo duas sessões com o servidor. Por outro lado, se o browser do usuário permitir a abertura de múltiplas janelas dentro do mesmo processo (algumas versões do IE fazem isso através do file->new window), teremos mais de uma janela de browser que irão compartilhar seus cookies temporários, pelo fato de estarem no mesmo processo, portanto compartilhando suas sessões nos sites visitados.

Otimização Máxima

O servidor web, pensando na otimização do seu funcionamento, não mantem espaços de sessão reservados sem necessidade. Por isso a sessão apenas se torna fixa depois que é feito algum acesso a sessão, quer seja feita a leitura do ID de sessão para seu uso pela aplicação quer seja guardada alguma informação na sessão.Antes disso, o servidor web cria e destroi a sessão a cada requisição do usuário. Pode parecer trabalhoso, mas ainda assim é melhor do que manter o consumo de recursos no servidor por mais tempo que o necessário. Entre performance e escalabilidade neste ponto o servidor escolhe a escalabilidade.

Normalmente este fato irá passar despercebido por todo desenvolvedor web e não terá importância alguma. Até hoje identifiquei apenas um raro uso de programação no evento start da sessão que é afetada por essa característica do servidor.

Parâmetros

Uma aplicação frequentemente precisa passar informações através de suas partes (que neste caso são as páginas). Exatamente devido ao fato do HTTP não manter conexão com o servidor, informações no servidor não são mantidas de forma tão simples (excetuando-se o uso de ambiente de sessão, conforme explicado anteriormente).Existem dois métodos de transmissão no protocolo HTTP que permitem a transmissão de parâmetros : GET e POSTMétodo GET

O método GET é a chamada comum que conhecemos, via URL. Por exemplo :

http://servidor/aplicacao/pagina.asp

Imaginemos que precisamos transmitir dois parâmetros para a página chamada "pagina.asp", os valores 10 e 20. Veja como fica :

http://servidor/aplicacao/pagina.asp?A=10&B=20

Observe que atribuimos um nome a cada valor, o valor 10 passou a ser chamado de "A" e o valor 20 passou a ser chamado de "B". A separação entre os dois valores ficou sendo o sinal de "&".Caso as informações transmitidas fossem string, precisariam ser formatadas de acordo com a codificação utilizada em URLs, pois alguns caracteres simplesmente não são aceitos em URLs. Por exemplo :

http://servidor/aplicacao/pagina.asp?nome=Jose%20Silva

Neste caso temos a informação "Jose Silva" sendo transmitida para "pagina.asp", porém o espaço em branco existente na informação foi codificado como %20

Método Post

O método POST é o método utilizado no preenchimento de formulários na web, por exemplo. A transmissão das informações é feita internamente no pacote HTTP e não diretamente no endereço que está sendo chamado, o que faz com que o usuário não veja o processo de transmissão acontecendo, como acontece com o método GET.O POST, porém, não precisa ser necessariamente utilizado apenas para formulários. Pode-se utilizar a página para guardar informações em campos Hidden (escondidos, o usuário não irá ver diretamente na página) e fazer com que um link ou um botão provoque o envio destas informações para o servidor.

O ASP.NET, por exemplo, adotou amplamente o método Post e cria por conta própria alguns campos hidden, tal como ViewState, para controlar as informações que serão mantidas através das diversas idas ao servidor, que no ASP.NET são chamadas de PostBacks.

Diferenças

O método GET é muito utilizado por search engines. Isso tem um motivo. Quando o usuário chega na sua página, o seu servidor e o seu site tem como capturar exatamente a página de onde ele veio, a URL. Mantendo parâmetros na URL, as ferramentas de busca permitem ao seu site identificar exatamente quais palavras o usuário utilizou para chegar ao seu site e até mesmo em que página do resultado da busca seu site se encontrava.Por outro lado, o método GET transmite uma impressão de insegurança, pelo fato de permitir que o usuário altere as informações livremente na URL.

Ocorre que a suposta segurança do método post é apenas ilusão, pois o usuário também possui meios para salvar a página em sua própria máquina, alterar os valores ocultos na página e enviar dados inválidos para o servidor. Portanto essa suposta maior segurança se baseia no desconhecimento do usuário sobre como fazer, o que normalmente não é considerado um método adequado de segurança.

A requisição do usuário

Veja alguns exemplos de endereços requisitados pelo usuário :

http://servidor/aplicacao/pagina.htmhttp://servidor/pagina.htmhttp://servidor/aplicacao/pagina.asphttp://servidor2/outraAplicacao/webPage.asphttp://servidor:1020/aplicacao/pagina.asphttp://servidor/aplicacao/pagina.txt

http://servidor/aplicacao/pagina.aspx

O servidor web nada mais é do que um entregador de arquivos, algo como um servidor de arquivos mas utilizando um protocolo especial e com alguns recursos adicionais.Nas requisições demonstradas, "servidor" é, obviamente, o nome do servidor que será acessado. Esse nome será traduzido para um endereço IP por um servidor DNS para que o servidor possa ser localizado, mas nesse ponto já estamos falando de características do TCP/IP.Podem existir, claro, várias aplicações rodando neste servidor. Por isso para o acesso ao servidor é necessário mais do que o nome, mas uma porta de comunicação. O protocolo HTTP sempre utiliza a porta de comunicação 80 como padrão, então quando não é especificado, a porta de comunicação com o servidor será porta 80 e o servidor web estará ouvindo esta porta. Porém, no 3o exemplo, fizemos a especificação de que a porta de conexão deveria ser a 1020 e não a porta 80, estaremos portanto nos conectando a um servidor web que foi configurado para estar ouvindo a porta 1020.Uma mesma máquina, fisicamente, pode possuir diferentes endereços IP. Isso já permite que o servidor web mantenha diferentes sites, direcionando os pedidos dos usuários para cada site conforme o endereço IP requisitado. Além disso os sites podem ser diferenciados por porta de comunicação (apesar de não ser uma boa prática pelo fato de confundir o usuário web), o que nos permite ainda termos vários sites ligados ao mesmo endereço IP.Por fim temos ainda o nome do servidor. O nome do servidor é traduzido pelo servidor DNS e nada impede que o servidor DNS traduza diferentes nomes (como no exemplo, servidor e servidor2), como sendo o mesmo endereço IP. Ainda assim o servidor web que receberá a requisição de ambos os endereços saberá com qual nome de servidor o usuário chegou até ele e poderá direcionar o usuário para um site distinto conforme o nome do servidor utilizado. Simplificando : Servidor e Servidor2, apesar de não parecer, podem estar localizados em uma mesma máquina fisicamente.Resumindo, um site é identificado por um conjunto único de 3 elementos : IP, porta de comunicação e nome do servidor.A partir do momento em que o IIS identifica o site para o qual irá desviar a chamada, o desvio é realizado. O site possui uma localização física, chamada de home directory (ou pasta base em português), é nessa localização física em que será feita a pesquisa pelo que foi requisitado. Na 2a URL, por exemplo, a "pagina.htm" será procurada na pasta base do site que encontra-se ligado ao nome "servidor", porta 80 e ip do nome "servidor" (traduzido pelo DNS).Na maioria das URLs de exemplo mais acima é feita uma requisição a uma sub-pasta chamada "aplicacao" . Essa sub-pasta pode ser um entre 3 elementos :

Uma pasta física

Localizada fisicamente baixo do home directory, de acordo com a estrutura de disco

Uma pasta virtual

Localizada em outro local qualquer, mas através do IIS inserida imediatamente abaixo da raiz do site, dando a impressão de estar no home directory

Uma aplicação virtual

Pode ser uma pasta física ou uma pasta virtual, tanto faz. Mas ao contrário destas duas, a aplicação virtual é marcada como sendo o ponto de inicio de uma nova aplicação. Essa "marca" determina que o IIS deve isolar as características de execução do site a partir deste ponto, ao contrário do que acontece com uma pasta física ou virtual, que usam as características de execução do site ou da primeira aplicação virtual encontrada acima delas.Esse isolamento significa, por exemplo, que a partir deste ponto a aplicação terá um controle de sessão isolado do restante do site.

Existem alguns arquivos de uma aplicação web que só funcionam se forem inseridos na raiz de uma aplicaço virtual ou site, tal como o global.asa e global.asax . O arquivo web.config irá gerar erro se for inserido fora de uma aplicação virtual ou raiz do site e contiver tags que apenas podem ser utilizadas nestes locais.

Com isso observamos que a estrutura hierárquica da URL não espelha obrigatoriamente a estrutura física existente no disco do servidor.Logo após a chamada do caminho "aplicacao" (nos exemplos), temos a chamada a um arquivo. A primeira questão interessante a observar é a extensão do arquivo.O IIS funciona como um entregador de arquivos, ele simplesmente entrega o arquivo para o usuário que fez a solicitação da URL. Porém antes de entregar propriamente, o IIS verifica se por acaso a extensão do arquivos não foi mapeada no servidor como tendo que ser processados por uma determinada aplicação ISAPI. Se isso aconteceu, o IIS dispara a aplicação transmitindo o arquivo e o que será transmitido para o client será o resultado do processamento.Nas URLs de exemplo, os arquivos txt e htm são entregues sem nenhum processamento, por não estarem mapeados a nenhuma aplicação ISAPI (supondo a configuração default). Os arquivos com extensão .ASP, porém, são entregues a aplicação ISAPI que faz o processamento do ASP 3.0. Já o arquivo .ASPX é entregue para a aplicação ISAPI que faz o processamento do ASP.NET.É justamente pelo fato de sites ASP 3.0 e sites em ASP.NET serem processados por aplicações ISAPI diferentes que é muito difícil compartilhar características de execução entre os dois sites, tal como o ambiente de sessão, por exemplo.No IIS 5.0 qualquer arquivo cuja extensão não estivesse mapeada era diretamente entregue ao usuário. Já no IIS 6.0, se não houver um mapeamento da extensão com uma aplicação ISAPI, o IIS verifica se a extensão era uma extensão conhecida, registrada no servidor como podendo ser entregue, só então o arquivo em questão era entregue.Essa forma de funcionamento explica várias questões, tais como :

- O motivo pelo qual realizar includes com arquivos com extensão .inc ou outra qualquer era falha de segurança, especialmente no IIS 5. Os includes precisam ter extensão .asp (ou aspx), do contrário o código fonte é acessível - uma extensão qualquer não passa pelo processador ISAPI e consequentemente um pedido direto ao arquivo gera uma entrega direta

- O motivo pelo qual é difícil impedir o acesso a arquivos de imagens no servidor - Os arquivos de imagens normalmente não passam pelo processador ISAPI, necessitando a criação de um handler para controlar sua entrega (ASP.NET)

Processamento

Quando o IIS dispara a aplicação ISAPI, inicia-se o processamento da página por parte de seu processador.É responsabilidade deste processador gerar o conteúdo que será enviado para o browser do usuário. Isso pode significar, por exemplo, ler dados da base de dados e organizar esses dados em formato HTML para serem enviados para a máquina do usuário.A forma como esse processamento e a comunicação com o IIS e o browser é realizado tem algumas características importantes que o desenvolvedor deve conhecer.Buffer

Buffer é um recurso que pode ou não ser usado. Trata-se da forma como a aplicação irá se comunicar com o IIS e consequentemente com o browser do usuário.Usar Buffer

Usar buffer significa que a aplicação irá guardar tudo que estiver sendo gerado como resposta para o usuário em um espaço de memória - o buffer - e apenas irá realizar o envio do conteúdo para o usuário quando o processamento terminar.

Não usar Buffer

Neste caso cada resposta que a aplicação gerar para o browser será imediatamente transmitida pela rede para a máquina do usuário, antes mesmo do fim do processamento.

Resultado

Usar ou não usar buffer significa apenas pedir isso ao IIS, através de uma única instrução na aplicação.Se o buffer não for usado, a aplicação terá uma maior performance aparente, pois imediatamente quando o processamento começar o usuário já começa a ver a página se formando em sua tela.Porém a maior performance é apenas aparente. O processamento não terminou no momento em que o usuário começa a ver a página e de fato o processamento irá demorar mais do que se a aplicação utilizasse buffer, pois a comunicação via rede com a máquina do usuário será feita em pedaços, portanto consumindo mais recursos.

O Buffer tem diversas outras implicações, conforme você irá observar nos próximos tópicos.

ScriptTimeout

A aplicação possui um tempo de timeout controlando a sua execução. Se a aplicação ficar mais do que este tempo sem dar nenhuma resposta para o usuário, a execução é interrompida com um erro de scriptTimeout.É importante observar a diferença entre o timeout de script e o timeout de sessão, dois timeouts totalmente diferentes que rondam uma aplicação web.O scriptTimeout está totalmente ligado ao Buffer. Isso porque o scripttimeout é o limite de tempo que a aplicação pode ficar sem enviar nada ao usuário. Portanto, se o buffer estiver sendo utilizado, é o limite total de execução de uma página, mas se o buffer não estiver sendo utilizado, é o tempo entre um envio e o envio seguinte durante a execução de uma página.

O script timeout normalmente tem um default de 90 segundos. Frequentemente manipula-se este tempo e o buffer quando temos uma página que realiza um processamento demorado no servidor. Desligar o buffer, por exemplo, pode fazer com que uma página pare de gerar script timeout.

Transmissão do cabeçalho do protocolo

Algumas tarefas exigem que, na transmissão para o client, a tarefa em questão seja transmitida no cabeçalho do protocolo HTTP.Isso faz com que tais tarefas sejam diretamente afetadas pelo uso ou não do Buffer. Se o buffer estiver sendo utilizado, a tarefa em questão pode ser realizada em qualquer parte do código. Se o buffer não estiver sendo utilizado, porém, a tarefa precisa ser realizada antes da primeira transmissão ser realizada para o client, o que pode acontecer até mesmo na tag "<html>".Como o ASP.NET e o IIS 6 passaram a usar buffer por default, isso se tornou uma característica esquecida, exceto quando surge a necessidade de desligar o buffer para algum grande processamento. As principais tarefas que fazem uso do cabeçalho do protocolo :

  • Redirecionamento Envio de cookies
  • Alteração do Mime/Type

Redirecionamento

Existem 3 instruções para redirecionar o fluxo de execução para uma outra página :

  • Response.Redirect Server.Transfer
  • Server.Execute

O Response.Redirect, mais antigo entre as 3 instruções, é baseado em um redirecionamento no client. Isso quer dizer o seguinte : Ao ser utilizado, ele envia para o client uma mensagem http dizendo ao browser que deve interromper a execução e ir para outro endereço, o que o browser faz de imediato.A mensagem de redirect usa o cabeçalho do protocolo HTTP, por isso está vinculada ao buffer conforme explicado anteriormente.As duas outras instruções são mais leves que o response.redirect pelo fato de ocorrerem apenas dentro do servidor e evitarem a comunicação com o client. Por outro lado o client não saberá o que aconteceu, pensando que ainda está visualizando a página que foi originalmente pedida.A diferença entre o Execute e o Transfer é que o Execute é tratado como uma chamada de sub-rotina, retornando ao ponto original da chamada, enquanto que o Transfer não faz o retorno.

Como o Execute e o Transfer ocorrem dentro do servidor, todo o contexto da chamada HTTP é mantido (por exemplo, parâmetros transmitidos pelo HTTP são mantidos), o que não acontece com o response.redirect

Definição de Mime/Type

Eventualmente o IIS não consegue identificar o tipo de dados que será retornado para o client. Por default, o tipo de dados é tratado como HTML, mas em alguns casos, como por exemplo, uma imagem gerada por um handler, o IIS não consegue identificar o tipo de dados sozinho.

A definição do mime/type é a identificação do tipo de dados de resultado de um processamento. Isso fica definido no cabeçalho do pacote HTTP e a consequencia é óbvia : a forma de definição fica interligada ao uso ou não do buffer.

Upload de Arquivos

O processo de upload de arquivos merece especial atenção pois exige configurações muito específicas que, se feitas de forma inadequada, podem comprometer a segurança do servidor. As configurações não estão tão diretamente ligadas ao HTTP, porém são de conhecimento essencial para o desenvolvedor e profissional de TI.

A realização de um upload de arquivo exige a mudança no formato do conteúdo POST. Isso faz com que as formas típicas de leitura de parâmetros não funcionem, exigindo o uso de componentes personalizados ou de uma programação personalizada para a interpretação do upload.

Tendo sido feita a interpretação do upload, o arquivo precisará ser gravado em banco de dados ou no disco do servidor. No caso de gravar o arquivo no disco do servidor, deve-se ter muito cuidado com a localização :

Além destes detalhes, alguns ambientes de desenvolvimento criam limites no tamanho do upload. Você precisará identificar se é esse o caso e alterar o limite conforme sua necessidade.

 

Mensagens de erro

A forma como o IIS irá tratar erros gerados pela aplicação pode variar também de acordo com o buffer. Isso porque se o IIS puder fazer o redirecionamento da execução para uma página de erro ele fará, mas se não puder irá anexar uma mensagem de erro na resposta que já foi enviada ao client.

Veja um artigo completo sobre este assunto

Conclusão

Com atuais tecnologias, como o ASP.NET, o programador fica mais distante das características específicas de protocolo da web. Porém o conhecimento ainda é muito necessário, pois em pontos específicos de aplicações complexas o desenvolvedor precisará manipular as características do protocolo.



Envie seus comentários sobre este artigo

Nome :

E-mail :

Comentários :


Avise-me quando houverem novos comentários nesta página

Veja abaixo os comentários já enviados :

Nome : Edson Domenech E-Mail : domenechbr@gmail.com
Show, todo programador de web, deve ter o mínimo de conhecimento, sobre os temas abordados. Parabéns, em poucos lugares podemos achar matérias com didática fácil, como essa.
Nome : Thiago E-Mail : thgoulart@hotmail.com
Fantástico Dennes! Uma linguagem simples e fácil de compreensão! Vc é o CARA!
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1