Quero adicionar um cabeçalho personalizado para a resposta recebida do servidor por trás do nginx.
Embora add_header
funcione para respostas processadas por nginx, ele não faz nada quando o proxy_pass
é usado.
Quero adicionar um cabeçalho personalizado para a resposta recebida do servidor por trás do nginx.
Embora add_header
funcione para respostas processadas por nginx, ele não faz nada quando o proxy_pass
é usado.
Respostas:
Existe um módulo chamado HttpHeadersMoreModule que oferece mais controle sobre os cabeçalhos. Ele não vem com o Nginx e requer instalação adicional. Com ele, você pode fazer algo assim:
location ... {
more_set_headers "Server: my_server";
}
Isso "definirá o cabeçalho de saída do servidor para o valor personalizado para qualquer código de status e qualquer tipo de conteúdo". Ele substituirá os cabeçalhos que já estão definidos ou os adicionará se não estiverem definidos.
Secure
e HttpOnly
sinalizar em um cookie de resposta ? O cookie de resposta de destino possui apenas o cookie name
e os expire
atributos.
add_header
funciona bem com proxy_pass
ou sem. Acabei de definir uma configuração em que usei exatamente essa diretiva. Tenho que admitir, porém, que também me esforcei ao configurar isso sem lembrar exatamente o motivo.
No momento, tenho uma configuração de trabalho e ela contém o seguinte (entre outros):
server {
server_name .myserver.com
location / {
proxy_pass http://mybackend;
add_header X-Upstream $upstream_addr;
}
}
Antes, o nginx 1.7.5
add_header trabalhava apenas em respostas bem-sucedidas, em contraste com o HttpHeadersMoreModule mencionado por Sebastian Goodman em sua resposta .
Desde nginx, 1.7.5
você pode usar a palavra always
- chave para incluir cabeçalhos personalizados mesmo em respostas de erro. Por exemplo:
add_header X-Upstream $upstream_addr always;
Limitação: Você não pode substituir o server
valor do cabeçalho usando add_header
.
add_header X-Upstream $upstream_addr always;
X-Upstream: 10.10.10.10
vs X-Upstream: 53c2d28edefdf501ab7c92e02a0c1687
(md5 provavelmente não é útil para mascarar a infraestrutura, mas transmite a ideia).
add_header
diretiva. Você não precisa enviá-los.
Como escreve oliver:
add_header
funciona bem comproxy_pass
ou sem.
No entanto, como Shane escreve, a partir do Nginx 1.7.5, você deve passar always
para obter add_header
respostas de erro, assim:
add_header X-Upstream $upstream_addr always;
Você pode tentar esta solução:
Em seu location
bloco, quando você usa, proxy_pass
faça algo assim:
location ... {
add_header yourHeaderName yourValue;
proxy_pass xxxx://xxx_my_proxy_addr_xxx;
# Now use this solution:
proxy_ignore_headers yourHeaderName // but set by proxy
# Or if above didn't work maybe this:
proxy_hide_header yourHeaderName // but set by proxy
}
Não tenho certeza se seria exatamente o que você precisa, mas tente alguma manipulação desse método e talvez o resultado se encaixe no seu problema.
Você também pode usar esta combinação:
proxy_hide_header headerSetByProxy;
set $sent_http_header_set_by_proxy yourValue;
location / { proxy_pass http://127.0.0.1:8080/; proxy_hide_header "Access-Control-Allow-Origin"; if ($http_origin ~* "^https://(example.com|www.example.com)$") { add_header Access-Control-Allow-Origin "$http_origin"; } }
Adicionar um cabeçalho com add_header
funciona bem com o passe de proxy, mas se houver um valor de cabeçalho existente na resposta, ele empilhará os valores.
Se você deseja definir ou substituir um valor de cabeçalho (por exemplo, substitua o Access-Control-Allow-Origin
cabeçalho para corresponder ao seu cliente para permitir o compartilhamento de recursos de origem cruzada), você pode fazer o seguinte:
# 1. hide the Access-Control-Allow-Origin from the server response
proxy_hide_header Access-Control-Allow-Origin;
# 2. add a new custom header that allows all * origins instead
add_header Access-Control-Allow-Origin *;
Assim, proxy_hide_header
combinado com add_header
lhe dá o poder de definir / substituir os valores do cabeçalho de resposta.
Uma resposta semelhante pode ser encontrada aqui em ServerFault
Nota: proxy_set_header
é para definir cabeçalhos de solicitação antes que a solicitação seja enviada, não para definir cabeçalhos de resposta (esses atributos de configuração para cabeçalhos podem ser um pouco confusos).