Comprimento de conteúdo é usado para descrever o comprimento de transferência do corpo da mensagem. No protocolo HTTP, há uma diferença entre o comprimento da entidade da mensagem e o comprimento de transmissão da entidade da mensagem, por exemplo, sob compressão gzip, o comprimento da entidade da mensagem é o comprimento antes da compressão, e o comprimento de transmissão da entidade da mensagem é o comprimento após a compressão gzip.
Em interações HTTP específicas, a forma como o cliente obtém o comprimento da mensagem é baseada principalmente nas seguintes regras:
Se a resposta for 1xx, 204, 304 ou solicitação principal, o conteúdo da entidade da mensagem é diretamente ignorado. Se houver Transfer-Encoding, o método em Transfer-Encoding é preferido para encontrar o comprimento correspondente. Por exemplo, o modelo Chunked. "Se houver um Comprimento de Conteúdo na cabeça, então esse Comprimento de Conteúdo representa tanto o comprimento do corpo quanto o comprimento de transmissão. Se o comprimento da entidade e o comprimento de transferência não forem iguais (por exemplo, a Codificação de Transferência for definida), então o Comprimento do Conteúdo não pode ser definido.Se a Codificação de Transferência estiver ativada, então o Comprimento do Conteúdo será ignorado”。 A vantagem dessa tradução de frases é que há apenas um ponto: com a Codificação de Transferência, não pode haver Comprimento de Conteúdo. Transmissão de alcance. Não prestei atenção, não li em detalhes :) Fechar a conexão através do servidor determina o comprimento da mensagem transmitida. (O solicitante não pode indicar o fim do corpo da solicitação fechando a conexão, pois isso deixaria o servidor sem chance de continuar respondendo.) Essa situação corresponde principalmente a conexões curtas, ou seja, modo não-manter a vida. HTTP 1.1 deve suportar modo chunk. Porque quando o comprimento da mensagem é incerto, essa situação pode ser tratada pelo mecanismo chunk. No cabeçalho contendo o conteúdo da mensagem, se houver um campo de comprimento de conteúdo, o valor correspondente do campo deve corresponder exatamente ao comprimento do tópico da mensagem. "O comprimento da entidade de uma mensagem é o comprimento do corpo da mensagem antes de qualquer codificação de transferência ser aplicada" Isto éSe houver um bloco, não pode haver comprimento de conteúdo 。
O mecanismo de conexão persistente do HTTP/1.0 foi introduzido posteriormente e é implementado por meio do cabeçalho Connection: keep-alive, que pode ser usado tanto pelo servidor quanto pelo cliente para informar um ao outro que não precisam desconectar a conexão TCP após enviar os dados para uso posterior.HTTP/1.1 exige que todas as conexões sejam persistentes,A menos que você adicione explicitamente Connection: próximo ao cabeçalho。 Então, na verdade, o campo de cabeçalho Connection em HTTP/1.1 não tem mais o valor de keep-alive, mas por razões históricas, muitos servidores web e navegadores ainda mantêm o hábito de enviar conexões Connection: keep-alive para conexões longas em HTTP/1.1.
Na verdade, os últimos podem ser quase ignorados, e um breve resumo é o seguinte:
1. Comprimento do Conteúdo: Se existir e for válido, deve ser exatamente o mesmo que o comprimento de transmissão do conteúdo da mensagem. (Testado para encurtar se fosse muito curto, e longo demais para causar tempo.) ) 2. Se houver Transfer-Encoding (o foco é fragmentado), não pode haver Conteúdo-Comprimento no cabeçalho, e ele será ignorado. 3. Se for usada uma conexão curta, o comprimento de transmissão da mensagem pode ser determinado diretamente ao fechar a conexão através do servidor. (Isso é fácil de entender) Combinado com outros recursos do protocolo HTTP, por exemplo, o Http1.1 não suportava manter o ativo. Então, as seguintes conclusões podem ser tiradas: 1. Em Http 1.0 e versões anteriores, o campo de comprimento de conteúdo é opcional. 2. Em http1.1 e versões posteriores. Se você se mantiver vivo, então conteúdo e bloco devem ser um dos dois. Se não for mantido vivo, é igual ao http1.0. conteúdo de duração.
|