Apache ProxyPass / RewriteRule com o sinalizador p: não retorna nenhum conteúdo quando a resposta tem um tipo de conteúdo de várias partes, por exemplo, imagens

3

Esta é uma continuação de uma pergunta anterior que foi implementado com uma pequena mudança. A seguir é a estrutura que vou falar. Meu objetivo é criar o túnel / proxy.

                         port 80                                 port 6103

Website (shared hosting) ----------> Tunnel (Dedicated hosting)  -----------> RETS Server

Eu usei o sinalizador RewriteRule with P (ou seja, ProxyPass) para reescrever os pedidos.

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^rets/server/(.*)$ http://rets-server:6103/rets/server/$1 [P]
</IfModule>

Ele está funcionando muito bem para quase todos os pedidos (até o momento), exceto aqueles cujo tipo de conteúdo de resposta é multi-partes (ou imagens). Dá resposta 200 OK com 0 comprimento de conteúdo.

A seguir, a resposta que recebo sem usar o proxy

< HTTP/1.1 200 OK
< Server: Apache-Coyote/1.1
< RETS-Version: RETS/1.5
< cache-control: private
< Server: StratusRETS/1.7
< MIME-Version: 1.0
< Content-Type: multipart/parallel; boundary=StratusRETS-XYZZY;charset=utf-8
< Transfer-Encoding: chunked
< Date: Tue, 24 Jul 2012 15:05:12 GMT
< --StratusRETS-XYZZY
Content-ID: E2356878
Content-Type: image/jpeg
Description: E2356878
Object-ID: 1
....

E seguir é a resposta quando o mesmo pedido é feito através do Proxy

< HTTP/1.1 200 OK
< Date: Tue, 24 Jul 2012 14:49:59 GMT
< Server: Apache-Coyote/1.1
< RETS-Version: RETS/1.5
< cache-control: private
< Content-Type: text/xml;charset=utf-8
< Content-Length: 0
< 

Eu também usei ProxyPass e ProxyPassReverse no httpd.conf. Mas sem sorte.

ATUALIZADO: Aqui estão as imagens dos pacotes enviados de um lado para outro com e sem proxy. p.s. Linhas pretas com fonte branca são a solicitação enviada do meu servidor IP (**. 1.2) para o servidor RETS (** 5.47) marcada com o pedido.

Sem proxy (funcionando bem)

Comproxy(nãofuncionaparaimagens)

E os cabeçalhos de solicitação da imagem são os seguintes (os cabeçalhos de resposta são colados acima.)

Sem proxy

GET /rets-treb3pv/server/getobject?Resource=Property&Type=Photo&ID=E2356878%3A%2A&Location=0 HTTP/1.1
Authorization: Digest username="user", realm="rets.server.net", nonce="518ae676272228c981854d964fa3c27e", uri="/rets-treb3pv/server/getobject?Resource=Property&Type=Photo&ID=E2356878%3A%2A&Location=0", cnonce="MDA0NTM2", nc=00000003, qop="auth", response="4d49b094301092839649703384bde9e8", opaque="5ccdef346870ab04ddfe0412367fccba"
Host: rets.server.net:6103
Accept: */*
Cookie: JSESSIONID=46D39B9B7AF641005F474F21D4EC46DB; RETS-Session-ID=0
RETS-Version: RETS/1.5
User-Agent: PHRETS/1.0
Accept: */*

Com proxy

GET /rets-treb3pv/server/getobject?Resource=Property&Type=Photo&ID=E2356878%3A%2A&Location=0 HTTP/1.1
Host: rets.server.net:6103
Authorization: Digest username="user", realm="rets.server.net", nonce="90b869eca69494b36bb2fe9123f2a32c", uri="/rets-treb3pv/server/getobject?Resource=Property&Type=Photo&ID=E2356878%3A%2A&Location=0", cnonce="MDA1Nzgw", nc=00000003, qop="auth", response="f4655108472a89d1b482d866667c34d9", opaque="5ccdef346870ab04ddfe0412367fccba"
Accept: */*, */*
Cookie: JSESSIONID=A4D1BDA0327440F64C4E67A6BDBFF521; RETS-Session-ID=0
RETS-Version: RETS/1.5
User-Agent: PHRETS/1.0
X-Forwarded-For: 127.0.0.1
X-Forwarded-Host: 127.0.0.1
X-Forwarded-Server: localhost
Connection: Keep-Alive

Podemos definitivamente ver pacotes extras indo e voltando com o status FIN e SYN. Alguma ideia, porque é isso?

    
por FatalError 24.07.2012 / 18:49

1 resposta

1

Infelizmente, parece que este aplicativo parece funcionar muito rápido com os padrões HTTP - é difícil dizer exatamente o que está incomodando, mas algumas das coisas que o Apache está fazendo (como combinar as duas coisas idênticas, Accept cabeçalhos em um único) são difíceis de fazer.

Algumas coisas tentam fazer com que as solicitações sejam mais semelhantes, na esperança de que uma dessas mudanças atinja o pedido, a ponto de não atrapalhar mais esse servidor HTTP.

SetEnv proxy-nokeepalive 1

A outra diferença principal é o X-Forwarded- headers - eles não podem ser desabilitados por meio da configuração, mas há um patch lá fora para desativá-los.

Com exceção de uma dessas mudanças em funcionamento, a única outra opção parece ser obter mais visibilidade para esse aplicativo RETS - não acho que haja uma maneira de fazer um bom registro de depuração? O cliente também parece estar se comportando de maneira um pouco diferente ao falar com o proxy, usando novas conexões para novas solicitações, em vez de reutilizar sua conexão aberta. Eu não suponho que haja um registro no cliente?

    
por 27.07.2012 / 20:37