Это продолжение предыдущий вопрос который был реализован с небольшими изменениями. Ниже приводится структура, о которой я собираюсь рассказать. Моя цель - создать туннель / прокси.
port 80 port 6103
Website (shared hosting) ----------> Tunnel (Dedicated hosting) -----------> RETS Server
Я использовал RewriteRule с флагом P (то есть ProxyPass), чтобы переписать запросы.
<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>
Он работает очень хорошо почти для всех запросов (которые я сделал до сих пор), кроме тех, чей тип содержимого ответа является составным (или изображениями). Он дает ответ 200 OK с нулевой длиной содержимого.
Ниже приводится ответ, который я получаю без использования прокси.
< 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
....
И ниже приведен ответ, когда тот же запрос выполняется через прокси.
< 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
<
Я также использовал ProxyPass и ProxyPassReverse в httpd.conf. Но не повезло.
ОБНОВЛЕНО: Вот изображения пакетов, отправленных туда и обратно с прокси и без него. p.s. Черные линии с белым шрифтом - это запрос, отправленный с моего IP (**. 1.2) на сервер RETS (** 5.47), помеченный тем, какой запрос был.
Без прокси (работает нормально)
С прокси (не работает для изображений)
И заголовки запроса для изображения следующие (заголовки ответов вставлены выше).
Без прокси
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: */*
С прокси
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
Мы определенно можем видеть дополнительные пакеты, перемещающиеся туда и обратно со статусом FIN и SYN. Есть идеи, почему?
К сожалению, похоже, что это приложение работает довольно быстро и слабо со стандартами HTTP - трудно сказать, что именно его расстраивает, но некоторые вещи, которые делает Apache (например, объединение двух бессмысленных идентичных Accept
заголовки в один) трудно что-либо сделать.
Несколько вещей, чтобы попытаться сделать запросы более похожими, в надежде, что одно из этих изменений приведет к тому, что запрос больше не будет нарушать этот привередливый HTTP-сервер.
SetEnv proxy-nokeepalive 1
Другое главное отличие - X-Forwarded-
заголовки - их нельзя отключить через конфигурацию, но есть патч там чтобы выключить их.
Если одно из этих изменений не работает, единственный другой вариант, кажется, - получить больше информации об этом приложении RETS - я не думаю, что есть способ сделать хороший журнал отладки? Также кажется, что клиент ведет себя немного иначе при разговоре с прокси, используя новые соединения для новых запросов вместо повторного использования открытого соединения. Я не думаю, что на клиенте есть логин?