1. Causas do problema
No anexo "Problemas Pós-Lançamento" das estatísticas de bugs após o lançamento de um projeto, há:
Como acumulação de experiências, esses problemas, causas e soluções serão incluídos na lista de verificação, então:
A primeira pergunta: O limite superior do parâmetro URL é referência precisa? Qual é o limite superior?
Segunda pergunta: Por que há um limite de dados no POST? O limite é de 128 mil?
2. Análise de problemas
1. O primeiro:
1) Não há limite superior de parâmetros na URL. O problema é que o IE tem um limite de comprimento para URLs.
2) A especificação do protocolo HTTP também não limita o comprimento da URL. Esse limite é uma limitação imposta por um navegador e servidor específicos. O limite do IE para o comprimento de URL é de 2083 bytes (2K+35). Para outros navegadores como Netscape, Firefox, etc., não há limite teórico de comprimento, e seu limite depende do suporte do sistema operacional. [Ref. 1]
3) "Parâmetros de comprimento variável são passados via URL" na verdade significa que o método GET é usado ao enviar o formulário, e não o método POST. O que causa esse possível erro é o uso do método GET para enviar dados de formulário. Porque o método GET passa os dados da URL para o servidor para processamento.
4) Note que esse limite é o comprimento total da URL, não apenas o valor do seu parâmetro e o comprimento do dado.
5) Como é o limite do IE para o comprimento da URL, tanto o método GET quanto o método POST têm essa limitação.
(Por favor, consulte o documento relacionado para detalhes sobre os métodos GET e POST do FORM [Ref. 2])
Recomendações:
1) Compreender o ambiente em que a aplicação está localizada, como o ambiente de navegador e servidor da aplicação web, e compreender suas limitações específicas de parâmetros.
2) Usar o método POST tanto quanto possível para enviar dados complexos. Nota: Quando o FORM não escreve o atributo do método, o padrão é usar o método GET.
Conclusão (escreva para a Checklist):
Ao enviar dados usando o método GET, você precisa considerar o limite de comprimento de URL de 2083 bytes no ambiente IE.
2. A segunda:
1) Teoricamente, o POST não tem limite de tamanho. A especificação do protocolo HTTP também não possui limite de tamanho.
2) "Há um limite de tamanho de 128K para dados POST" não é preciso o suficiente, não há limite para dados POST, e o poder de processamento do processador do servidor desempenha um papel limitante.
3) Para programas ASP, há um limite de 100K de comprimento de dados quando o objeto Request processa cada campo de formulário. Mas com o Request.BinaryRead não existe essa limitação. Para soluções que exigem processamento de mais de 100 mil dados do domínio do formulário, consulte [Ref. 3] abaixo.
4) Por extensão, para o IIS 6.0, a Microsoft aumentou as restrições por razões de segurança [Ref. 4]. Também precisamos prestar atenção a:
O IIS 6.0 tem como padrão um máximo de 200 KB de dados ASP POST, e o limite é de 100 KB por campo de formulário.
O tamanho padrão dos arquivos de upload do IIS 6.0 é 4MB.
O IIS 6.0 tem como padrão um cabeçalho máximo de requisição de 16KB.
Essas limitações não estavam disponíveis antes do IIS 6.0.
Recomendações:
1) Conhecer as configurações padrão do ambiente de execução ajudará você a projetar e resolver rapidamente os problemas que surgirem.
2) A versão do servidor deve ser considerada. Cada versão do IIS possui diferentes configurações padrão para esses parâmetros, então, se necessário, encontre informações e compile uma tabela comparativa. Dessa forma, há uma referência para desenvolvimento e testes.
3) Essas limitações do IIS 6.0 são na verdade apenas suas configurações padrão, e você pode modificá-las no ambiente real da aplicação.
Em WINNT/system32/inetsrv/MetaBase.xml, a definição padrão é:
AspBufferingLimit="4194304" corresponde ao tamanho máximo do arquivo enviado
AspMaxRequestEntityAllowed="204800" corresponde à quantidade máxima de dados no POST
...
Conclusão (escreva para a Checklist):
Ao usar ASP, é preciso considerar que o formulário POST tem um limite de 100KB por campo para processamento geral de leitura. Considere se deve usar o Request.Binary.
|
Publicado em 08/03/2018 10:18:07
|
|
|
|
