Hoje eu quero compartilhar com vocês o tema é "ser tolerante com a diversidade: os dados da entidade HTTP."
Esta palestra é a primeira palestra "capítulo Avançado" de agora em diante, vou falar de um comprimento contínuo de 8 a análise detalhada em uma variedade de HTTP campos de cabeçalho de protocolo, incluindo a definição, função, uso e precauções e assim por diante. Escola terminou estes cursos, você pode compreender plenamente o protocolo HTTP.
No "Basics" anteriores em nossa compreensão da estrutura do HTTP pacotes, sabe uma mensagem HTTP é um "cabeçalho + corpo", composto de. Mas, então, focar é o cabeçalho, não relacionada com o corpo. Assim, a primeira palestra "capítulo Avançado" A partir de HTTP no corpo.
Que codifica para o tipo de dados
Na pilha de protocolos TCP / IP, a transmissão de dados são basicamente "cabeçalho + corpo" formato. No entanto, TCP, UDP protocolo de camada de transporte é porque eles não se importam que corpo de dados é, desde que os dados são enviados para a outra parte, mesmo que seja para completar a tarefa.
O protocolo HTTP é diferente, ele é o protocolo de camada de aplicação, após os dados chega ao trabalho só pode ser dito para ser metade concluída, também deve ser dito que esses dados de aplicação camada superior para o trabalho ou o aplicativo superior "saberá o que fazer."
Você pode imaginar, se não informar HTTP tipo de dados da função, o servidor "uma grande massa" de dados enviados para o navegador, o navegador vê é uma "caixa preta", desta vez como fazê-lo?
Claro, ele pode "adivinhar". Porque um monte de dados é um formato fixo, de modo a verificar através dos primeiros bytes de dados pode ser capaz de saber que esta é uma imagem GIF ou um arquivos de música MP3, mas esta é sem dúvida uma forma muito ineficiente, e haverá uma grande chance verificar o tipo de arquivo.
Felizmente, muito antes do nascimento do protocolo HTTP já temos uma solução para este problema, mas é usado no sistema de e-mail, de modo que o e-mail pode enviar quaisquer outros do que o código ASCII de dados, o nome do programa chamado " multipurpose Internet mail extensions "(extensões multipurpose Internet mail), referidos como MIME.
MIME é um monte de padrões, mas apenas HTTP "furtos" tomar uma parte dela, usado para marcar o corpo de tipo de dados, que é o que normalmente sempre ouvir o " MIME do tipo ."
dados MIME em oito categorias, cada categoria é subdividida em uma pluralidade de sub-classes, a forma "tipo / subtipo" string bastante inteligente, apenas de acordo com as características do texto simples HTTP, é possível facilmente no campo de cabeçalho HTTP.
Aqui uma breve olhada em algumas categorias listadas no HTTP freqüentemente encontradas:
texto: formato de texto que é dados legíveis, devemos ser os mais familiarizados com text / html, e representa os documentos de hipertexto, além de texto de texto simples / texto simples e de estilo / css e assim por diante.
Imagem: ou seja, o arquivo de imagem, existem image / gif, image / jpeg, image / png como.
De áudio / vídeo: dados de áudio e vídeo, tais como áudio / mpeg, vídeo / mp4 similares.
aplicação: formato de dados não é fixo, pode ser um texto binário pode ser, ele deve ser explicado pela aplicação superior. Comuns são application / json, application / javascript, application / pdf, etc. Além disso, se você realmente não sei que tipo de dados é, como já foi dito "caixa preta", será application / octet-stream, que é binário opaco dados.
Mas somente um tipo MIME não é suficiente, porque HTTP, a fim de economizar largura de banda de transmissão de dados e às vezes até mesmo comprimido, a fim de não deixar o navegador continua a "palpite", também precisa ter um "tipo de codificação", dizer o que os dados são codificados com formato, para que o outro lado pode corretamente descomprimir, para restaurar os dados originais.
Comparado tipo MIME é, tipo de codificação muito menos, comuns apenas os três seguintes maneiras:
gzip: GNU zip formato de compressão, é formatos de compressão populares a maioria da Internet;
deflate: zlib (deflate) formato de compressão, a popularidade perdendo apenas para gzip;
lg: Um novo algoritmo de compressão (Brotli) especificamente para HTTP optimização.
campo de cabeçalho dos tipos de dados utilizados
Com o tipo de MIME e tipo de codificação, independentemente do navegador ou o servidor pode facilmente identificar o tipo de corpo, ele será capaz de processar os dados corretamente.
Para este HTTP final protocolo define dois Aceitar pedido de campo de cabeçalho e dois campos de cabeçalho entidade de conteúdo para o cliente eo servidor " negociação de conteúdo ." Ou seja, o cliente informa o servidor com o cabeçalho Accept espero que tipo de dados são recebidos, eo servidor usando o cabeçalho de conteúdo para dizer ao cliente o que realmente dados transmitidos.
Aceitar marcador de campo é o cliente apreciado tipo MIME, pode ser usado "" uma pluralidade de tipos são listados como separador, para que o servidor tem mais opções, tais como a cabeça do seguinte:
| Aceitar: text / html, application / xml, image / WebP, image / png |
Copie o código
Isso é para dizer ao servidor: "Eu posso entender HTML, texto XML, bem como WebP e PNG, por favor me dê esses quatro tipos de dados formatados"
Assim, o servidor será usado nos campos de cabeçalho pacote de resposta no Content-Type diz o verdadeiro tipo de dados de entidade:
| Content-Type: text / html |
|
| Content-Type: image / png |
Copie o código
Ver esta mensagem no tipo de navegador é "text / html" saber arquivo HTML, chama o mecanismo de layout para processar uma página, consulte "image / png" que este é um arquivo PNG, ele aparecerá na página a imagem.
Accept-Encoding marcadores de campo são formato de compressão suportada pelo cliente, como o dito acima gzip, desinflar semelhante, também pode ser usado "" várias listas, o servidor pode escolher um dos dados comprimidos, o formato de compressão realmente utilizados em resposta campo de cabeçalho Content-Encoding no.
| Accept-Encoding: gzip, deflate, br |
|
| Content-Encoding: gzip |
Copie o código
No entanto, esses dois campos podem ser omitidos, se não há nenhum campo pacote de solicitação Accept-Encoding, isso indica que o cliente não suporta os dados comprimidos; se não houver pacotes Content-Encoding campo de uma mensagem de resposta, isso significa que os dados de resposta não é comprimido.
Tipo de linguagem e codificação
Tipo de MIME e tipo de codificação para resolver o problema de compreensão computador de dados do corpo, mas a Internet em todo o mundo, pessoas de diferentes países em diferentes regiões usar um monte de línguas diferentes, embora sejam text / html, mas como fazer o show navegador todos podem compreender a linguagem pode lê-lo?
Esta é de fato a "internacionalização" do problema. HTTP usa um tipo de dados com uma solução semelhante, e com a introdução de dois conceitos: o tipo de linguagem e conjunto de caracteres.
O chamado " tipo de linguagem " é o uso humano da linguagem natural, como o Inglês, chinês, japonês, etc., mas estes linguagem natural pode também filiado dialeto regional, por isso a necessidade de ter uma clara distinção entre quando usar "tipo-subtipo" de formar, mas aqui diferentes formatos e tipo de dados separador não "/", mas é "-" .
Alguns exemplos: en representar qualquer Inglês, en-US para US Inglês, en-GB para Inglês Britânico, e Chinês zh-CN diz que usa com mais frequência.
Algo sobre o processamento computacional da linguagem natural há um mais problemático chamado de "conjunto de caracteres".
No desenvolvimento dos primeiros computadores, pessoas de vários países e regiões, "fragmentação", inventou um monte de maneiras de texto codificação de caracteres punho, como mundo Inglês-falando com ASCII, mundo chinês com GBK, BIG5, japonês e outro mundo com Shift_JIS. O mesmo pedaço de texto exibido em uma codificação normal, torna-se possível para outra confusão após a codificação.
Então, em seguida, apareceu Unicode e UTF-8, todas as línguas do mundo estão alojados em um esquema de codificação, onde, UTF-8 conjunto de caracteres tornou-se um padrão na internet.
O tipo de linguagem utilizada campos de cabeçalho
O mesmo, HTTP protocolos usando a solicitação de campo Aceitar cabeçalho e cabeçalho entidade campos de conteúdo para cliente e servidor "na linguagem e codificação de negociação de conteúdo ."
Accept-Language cliente tag campo apreciado linguagem natural, mas também permite "" uma pluralidade de tipos de delimitadores são listados, por exemplo:
| Accept-Language: zh-CN, zh, en |
Copie o código
O cabeçalho de solicitação informa ao servidor: "Dê-me as melhores caracteres chineses zh-CN, se não usar outros dialetos chineses, se você não dá o Inglês."
Assim, o servidor deve responder com uma mensagem no campo de cabeçalho Content-Language conta o tipo de linguagem usada dados entidade cliente:
| Content-Language: zh-CN |
Copie o código
Pedido no campo de cabeçalho HTTP no conjunto de caracteres utilizado é o Aceite-o Charset , Content-Charset cabeçalho, mas a resposta não é realmente correspondente a, mas no Content-Type após o tipo de dados do campo representado por "charset = xxx", isto requer atenção especial.
Por exemplo, o navegador solicita GBK, ou UTF 8 conjunto de caracteres, em seguida, o servidor retorna a codificação UTF-8, este é o seguinte:
| Aceitar-Charset: gbk, utf-8 |
|
| Content-Type: text / html; charset = UTF-8 |
Copie o código
Mas agora os navegadores suportam vários conjuntos de caracteres, normalmente não envia Accept-Charset, eo servidor não irá enviar um Content-Language, porque a linguagem usada pode ser inferida a partir do conjunto de caracteres, é geralmente só na solicitação com antecedência há Accept-Language campo, só haverá uma resposta em campo antecedência Content-Type.
O valor da negociação de conteúdo de qualidade
Quando usado em Aceitar, Accept-Encoding, Accept-Language campo de cabeçalho no pedido e similares no protocolo HTTP para negociação de conteúdo, também pode ser representado por um especial "q" pesos parâmetros para priorizar, onde "q" é " fator de qualidade "meios.
pesos máximos são 1, um valor mínimo de 0,01, um valor default é 1, isto significa que, se o valor 0 é rejeitado. Sob a forma de um tipo particular de dados é adicionado após o código ou linguagem ";", em seguida, "q = valor".
Aqui para lembrar que "" uso na maioria das linguagens de programação "" pontuam o tom melhor do que "" e na negociação de conteúdo HTTP é realmente apenas revertida over ";" o que significa menos do que " "a.
Aceitar exemplo, os seguintes campos:
| Aceitar: texto / html, aplicação / XML; q = 0,9, * / *; q = 0,8 |
Copie o código
Ela representa o melhor navegador que você deseja usar o arquivo HTML, o peso é 1, seguido pelo arquivo XML, o peso é de 0,9, e, finalmente, qualquer tipo de dados, o peso é de 0,8. Depois que o servidor recebe o cabeçalho de solicitação, ele irá calcular o peso, e, em seguida, saída HTML ou prioridade XML de acordo com a situação real.
resultados das negociações conteúdo
processo de negociação de conteúdo é opaco, o algoritmo usado por cada servidor Web não são os mesmos. Mas, às vezes, o servidor responderá com antecedência para pagar mais em um Vary campo, registrada no conteúdo do servidor de referência de campo de cabeçalho de solicitação de negociação, dado bit de informação, tais como:
| Vary: Accept-Encoding, User-Agent, Aceitar |
Copie o código
Vary neste campo indica que o servidor baseado no Accept-Encoding, User-Agent e cabeçalho Accept campo três, em seguida, decidiu enviar o pacote de resposta.
Vary campo pode ser considerado em resposta a um especial "versão tag" mensagens. Aceitar alterações cada vez que os primeiros pedidos de pares, Vary vai mudar junto com o pacote de resposta. Em outras palavras, o mesmo URI pode ter várias "versões" diferentes, usado principalmente no meio do link de transmissão de servidores proxy para serviço de cache, haverá outra menção ao falar sobre "HTTP cache" depois disso.
Hands-on experimentos
Acima de terminar a parte teórica, o próximo passo é o real hands-on. Você pode usar nosso ambiente de teste, há um mime no diretório diretório www, que é pré-armazenado por vários arquivos, você pode usar para acesso URI na forma de, por exemplo, "/ 15-1 name = arquivo?":
| http://www.chrono.com/15-1?name=a.json |
|
| http://www.chrono.com/15-1?name=a.xml |
Copie o código
Abra as Ferramentas de Desenvolvimento no Chrome onde você pode ver Aceitar e Chefe de Conteúdo:
Você também pode copiar todos os arquivos para mime diretório, como arquivo, MP3, imagens, vídeos, etc., então o acesso Chrome para observar mais do tipo MIME.
Após essas experiências, você também pode deixar o ambiente experimental, o acesso directo aos principais portais, dê uma olhada na rede HTTP do mundo real pacotes parecer.
resumo
Hoje nós aprendemos no tipo de dados HTTP eo tipo de linguagem, aqui hoje para ser um resumo do conteúdo.
Os dados indicam que tipo de dados entidade é usar um tipo MIME, o campo de cabeçalho associado Aceitar e Content-Type;
A compressão de dados representação da entidade de dados codificada, associado Accept-Encoding campo de cabeçalho e de conteúdo de codificação;
Ele representa o tipo de linguagem da linguagem natural, os dados relacionados entidade cabeçalho campo, eo Accept-Language Content-Language;
dados de entidade conjunto de codificação de caracteres associada Accept-Charset cabeçalho campo e Content-Type;
Os clientes precisam ser "negociação de conteúdo", o servidor retorna os dados necessários na maioria pedido adequado campo de cabeçalho para o servidor para usar o Aceite o como antecipadamente;
Aceitar campo de cabeçalho e similares podem ser usados "" também pode ser usado número de possíveis opções na ordem listada, '; q =' parâmetro para especificar o peso exato.
Lição no trabalho
Tente explicar este pedido cabeçalho "Accept-Encoding: gzip, deflate; q = 1,0, *; q = 0,5, br; q = 0", e, em seguida, simular o que a resposta para o primeiro servidor.
Suponha que você queira usar o método POST para enviar alguns dados em formato JSON para o servidor, que contém os chineses, o cabeçalho pedido deve olhar como ele?
Tente usar expressa metáfora recibo de entrega sobre MIME, codificação conceitos.