Proxy reverso do Apache não preservando cabeçalhos

4

Alguém sabe se algo estranho está acontecendo? Parece que minha configuração de proxy reverso não preserva os cabeçalhos de cache corretos do virtualhost original.

Deixe-me explicar ...

Atualmente, estou usando o PHP Slim para criar uma API para meu aplicativo da web. Ele tem seus próprios mecanismos de cache, que são configurados e funcionando bem. Então, ao visitar o recurso api.example.com/info por exemplo, eu tenho um Last-Modified que está definido, o que permite que ele seja armazenado em cache (ele não muda com muita frequência).

Assim, os cabeçalhos são parecidos com:

Request URL:http://api.example.com/info
Request Method:GET
Status Code:304 Not Modified

Solicitar cabeçalhos

Accept:text/html,application/xhtml xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-GB,en-US;q=0.8,en;q=0.6
Cache-Control:max-age=0
Connection:keep-alive
Host:api.example.com
If-Modified-Since:Mon, 04 Oct 2010 08:00:52  1100
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5

Cabeçalhos de resposta

Connection:Keep-Alive
Date:Tue, 19 Jun 2012 22:34:45 GMT
Keep-Alive:timeout=5, max=100
Server:Apache/2.2.21 (Win64) PHP/5.3.8
Vary:Accept-Encoding

O que mostra que o recurso retorna com um 304 - foi recuperado do cache. Ótimo!

No entanto, o aplicativo da Web acessa isso de um proxy reverso (problemas de domínio cruzado). Ao acessar o mesmo recurso exato, desta vez a partir de app.example.com/api/info , ele retorna com um código 200. Também é notavelmente mais lento para carregar, o que me faz pensar que algo não está funcionando.

Desta vez, os cabeçalhos são

Request URL:http://app.example.com/api/info
Request Method:GET
Status Code:200 OK

Solicitar cabeçalhos

Accept:text/html,application/xhtml xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-GB,en-US;q=0.8,en;q=0.6
Cache-Control:max-age=0
Connection:keep-alive
Host:app.example.com
If-Modified-Since:Mon, 04 Oct 2010 08:00:52 GMT
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5

Cabeçalhos de resposta

Connection:Keep-Alive
Content-Encoding:gzip
Content-Length:1959
Content-Type:application/json
Date:Tue, 19 Jun 2012 22:41:01 GMT
Keep-Alive:timeout=5, max=100
Last-Modified:Mon, 04 Oct 2010 08:00:52 GMT
Server:Apache/2.2.21 (Win64) PHP/5.3.8
Vary:Accept-Encoding
X-API-Version:v1.0
X-Powered-By:PHP/5.3.8, Slim

Alguma ideia? Desculpe pela quantidade de informações do cabeçalho acima - não quis deixar nenhuma informação.

    
por crawf 20.06.2012 / 00:46

1 resposta

2

Quando eu comparo o seu pedido de exemplo, vejo algumas diferenças entre eles.

por exemplo. a segunda resposta (através do proxy) inclui um

Content-Encoding:gzip

Linha. Talvez seu proxy reverso adicione um filtro de compactação gzip antes de entregar os resultados. O que poderia significar: o recurso principal não foi alterado e o proxy alterou o conteúdo compactando-o e, assim, rotulou isso como "novo conteúdo".

Outra diferença está no seu pedido: no seu primeiro pedido, você envia:

If-Modified-Since:Mon, 04 Oct 2010 08:00:52 +1100

mas na sua segunda solicitação o timeoffset +1100 está faltando, então você está enviando outra hora de modificação.

    
por 19.03.2014 / 08:59