Quase tudo o que vê no seu navegador é transmitido para o seu computador através do protocolo HTTP. Por exemplo, quando abriu esta página do artigo, o seu navegador enviou muitos pedidos HTTP(Request) e recebeu muitas respostas(Response).
HTTP cabeçalhos (Header) são uma parte importante destes HTTP pedidos e respostas, transmitem informações sobre o navegador do cliente, a página solicitada, o servidor, etc.
Neste tutorial vamos mostrar-lhe como obter a informação de que necessita Request Headers. Este tutorial guia sobre como obter as informações que nos interessam nos cabeçalhos dos pedidos (Request Headers) e definir certos valores para os cabeçalhos de resposta necessários (Response Headers).
A forma mais fácil de obter informações sobre o conteúdo de Request Headers é a execução de um pedido num pedido publicado.
- Ir para a ferramenta de desenvolvimento (F12).
- Mudar para o Networks tab.
- Seleccionando o pedido submetido da lista.
- Mudar para o separador Headers tab e encontrar o Request Headers secção.
Como utilizar o AppMaster para interagir com os Cabeçalhos de Resposta-Pedido
No AppMasterbackend designer pode obter informações sobre o cabeçalho do pedido se o seu nome estiver especificado no Get Request Headers bloco do processo empresarial.
- Name [string] - Nome do cabeçalho;
- Value [string] - Valor do cabeçalho;
Para adicionar o costume Header na resposta - o Set Response Header é utilizado um bloco.
- Name[string] - Nome do cabeçalho;
- Value[corda] - Valor do cabeçalho;
Há muitos Request Headers existem, mas algumas delas são descritas abaixo (a informação é retirada de https://www.w3.org/Protocols/HTTP/HTRQ_Headers.html):
- From - No formato de correio da Internet, isto dá o nome do utilizador requerente. Este campo pode ser utilizado para fins de registo e uma forma insegura de protecção de acesso. A interpretação deste campo é que o pedido está a ser executado em nome da pessoa dada, que aceita a responsabilidade pelo método executado. O endereço de correio da Internet neste campo não tem de corresponder ao anfitrião da Internet que emitiu o pedido. (Por exemplo, quando um pedido é passado através de um portal, então deve ser utilizado o endereço original do emitente). O endereço postal deve, se possível, ser um endereço postal válido, quer seja ou não de facto um endereço postal da Internet ou a representação postal da Internet de um endereço em algum outro sistema de correio.
- Accept - Este campo contém uma lista de esquemas de representação separados por ponto e vírgula ( Content-Type metainformation values) que serão aceites na resposta a este pedido. O conjunto dado pode, evidentemente, variar de pedido para pedido do mesmo utilizador.
Exemplo:
Aceitar: text/plain, text/html
Aceitar: text/x-dvi; q=.8; mxb=100000; mxt=5.0, text/x-c - Accept-Encoding- Semelhante a Accept, mas lista os tipos de codificação de conteúdo que são aceitáveis na resposta.
Exemplo:
Aceito-Codificação: x-comprimir; x-zip - Referer - Este campo de cabeçalho opcional permite ao cliente especificar, em benefício do servidor, o endereço ( URI ) do documento (ou elemento dentro do documento) a partir do qual o URI no pedido foi obtido. Isto permite a um servidor gerar listas de back-links para documentos, para interesse, registo, etc. Permite a localização de ligações defeituosas para manutenção. Se for dado um URI parcial, este deve ser analisado em relação ao URI do objecto do pedido.
Exemplo:
Referidor: http://www.w3.org/hypertext/DataSources/Overview.html - Authorization - Se esta linha estiver presente, contém informações de autorização. O formato é Para Ser Especificado (TBS). O formato deste campo está em formato extensível. A primeira palavra é uma especificação do sistema de autorização em uso.
Exemplo:
Autorização: Portador BtHKEsVs5mNNtNf7UWoVwoVwjJzFqLOzucA - Accept-Language - Semelhante a Accept, mas lista os valores linguísticos que são preferíveis na resposta. Uma resposta numa língua não especificada não é ilegal.
- User-Agent - Esta linha, se presente, dá o programa de software utilizado pelo cliente original. Isto é para fins estatísticos e para o rastreio de violações de protocolo. Deve ser incluída. A primeira palavra em branco delimitada deve ser o nome do produto de software, com uma barra opcional e um designador de versão. Outros produtos que fazem parte do agente do utilizador podem ser colocados como palavras separadas.
Exemplo:
Agente-utilizador: LII-Cello/1.0 libwww/2.5
Response Headers exemplos:
- Allowed - Lista o conjunto de pedidos que o utilizador requerente está autorizado a emitir para este URL. Se esta linha de cabeçalho for omitida, os métodos permitidos por defeito são"GET HEAD".
- Public - Como permitido, maslista os pedidos que qualquer pessoa pode utilizar. Se omitido, o padrão é apenas"GET".
- Content-Length - Implica que o corpo é binário e deve ser lido directamente da ligação de comunicações, sem linhas de análise, etc. Quando os dados fazem parte do pedido, previne a fuga e a desvinculação da sequência de terminação.
- Content-Encoding - Especifica o mecamismo de codificação utilizado. Actualmente em uso apenas x-compress e x-gzip.
- Content-Type - especifica o tipo de documento.
- Content-Length - Implica que o corpo é binário e deve ser lido directamente da ligação de comunicações, sem linhas de análise, etc. Quando os dados fazem parte do pedido, previne a fuga e a desvinculação da sequência de terminação.
- Last-Modified - O objecto da última vez foi modificado, ou seja, a data desta versão, se o documento for um "documento vivo".
Vejamos um exemplo de obter o IP do utilizador e o seu valor de Cookie a partir dos Cabeçalhos de Pedido.
Para obter o IP do utilizador é utilizado o x-real-ip . Os Cabeçalhos de Pedido de Cookie fornecem informações simbólicas de Cookie .
A BP parece:
No próximo passo, tem de ser criada uma BP
A UI parece:
Finalmente, o resultado é mostrado abaixo. O utilizador recebe a informação dos cabeçalhos assim que o botão é clicado(onClick trigger no fluxo de trabalho do botão) e os títulos da Etiqueta são actualizados com esta informação(Label Update Properties).