Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

This is a continuation of a previous question which has been implemented with a little change. Following is the structure I am going to talk about. My goal is to create the Tunnel/Proxy.

                         port 80                                 port 6103

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

I used the RewriteRule with P flag (i.e. ProxyPass) to rewrite the requests.

<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>

It is working very well for almost all the request (I have done so far) except the ones whose response's content type is multi-part (or images). It gives response 200 OK with 0 content length.

Following is the response I receive without using the 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
....

And following is the response when same request is made through the 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
< 

I have also used ProxyPass and ProxyPassReverse in httpd.conf. But, no luck.

UPDATED: Here is the images of Packets sent back and forth with and without proxy. p.s. Black lines with white font are the request sent from my IP (*.1.2) to RETS server (*5.47) tagged with what request was.

Without Proxy (Working fine) Without Proxy (Working fine)

With Proxy (Not working for images) With Proxy (Not working for images)

And the Request Headers for the image are as follows (response headers are pasted above.)

Without 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: */*

With 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

We can definitely see extra packets going back and forth with status FIN and SYN. Any idea, why is that?

share|improve this question
    
Have you confirmed that the content returned to the proxy has a non-zero content length when the request is made via the proxy? mod_proxy doesn't tend to modify response headers. Use tcpdump to confirm, if possible, but the different Server header, advertising Tomcat instead of StratusRETS/1.7 as in the working request, tells me that something's different in a significant way. –  Shane Madden Jul 25 '12 at 6:25
    
Hey @FatalError, I think what would really help here (if at all possible) is for you to do a packet dump of the traffic between the proxy and the RETS server. Ignore all of the crap, but pay attention to the headers. Looks like the output you supplied in the question is from curl? I think if you do curl -v you can see the headers being sent too. It would be interesting to see the difference between the headers sent by curl, and those sent by your proxy. –  Leigh Jul 27 '12 at 12:37
    
@Leigh - Please check the updates.. You may now can point out what is wrong actually. –  FatalError Jul 27 '12 at 16:27
    
@ShaneMadden - Can you look at it also? –  FatalError Jul 27 '12 at 16:28
add comment

1 Answer

Unfortunately, it looks like this application seems to play pretty fast and loose with HTTP standards - it's hard to tell what exactly is upsetting it, but some of the things that Apache is doing (like combining the two nonsense identical Accept headers into a single one) are hard to do anything about.

A couple of things to try to get the requests to be more similar, in the hopes that one of those changes will get the request to the point that it's no longer upsetting this finicky HTTP server.

SetEnv proxy-nokeepalive 1

The other main difference is the X-Forwarded- headers - they can't be disabled through configuration, but there's a patch out there to turn them off.

Barring one of these changes working, the only other option seems to be to gain more visibility into this RETS application - I don't suppose there's a way to do some good debug logging? The client also seems to be behaving a bit differently when talking to the proxy, using new connections for new requests instead of re-using its open connection. I don't suppose there's logging on the client?

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.