Eu testei isso com um script bash simples contra um domínio que estou executando por trás de um ELB:
S='a';
URL='http://example.com/?foo=';
while true;
do
echo $URL$S | wc -c;
curl -I "$URL$S";
S=$S$S;
done
Isso funcionou bem por um tempo:
2081
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Date: Tue, 05 Feb 2013 15:01:44 GMT
Server: Apache/2.2.22 (Ubuntu)
Vary: Accept-Encoding
Connection: keep-alive
4129
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Date: Tue, 05 Feb 2013 15:01:46 GMT
Server: Apache/2.2.22 (Ubuntu)
Vary: Accept-Encoding
Connection: keep-alive
Mas falhou ao cruzar a barreira do comprimento de 8192:
8225
HTTP/1.1 414 Request-URI Too Large
Content-length: 337
Content-Type: text/html; charset=iso-8859-1
Date: Tue, 05 Feb 2013 15:01:47 GMT
Server: Apache/2.2.22 (Ubuntu)
Vary: Accept-Encoding
Connection: keep-alive
16417
HTTP/1.1 414 Request-URI Too Large
Content-length: 337
Content-Type: text/html; charset=iso-8859-1
Date: Tue, 05 Feb 2013 15:01:47 GMT
Server: Apache/2.2.22 (Ubuntu)
Vary: Accept-Encoding
Connection: keep-alive
As solicitações com falha foram registradas em um arquivo diferente pelo Apache porque a string GET
vem antes do cabeçalho Host:
e, portanto, o Apache nunca determinou qual vhost usar.
No entanto, era ainda o Apache respondendo, e não o ELB, até mais de 128 KB em uma única string GET
. A solicitação completa de 128 KB foi registrada no arquivo de log padrão do Apache. Após 256 KB, curl
falhou ao processar a solicitação.
Não parece haver qualquer limite de tamanho de URL nos Amazon ELBs.