solprovider@xxxxxxxxxx wrote:
I am not the original OP, but for me that's a great summary, many thanks. I think I'll need a while to digest it, but maybe I'll finally understand proxies, and mod_rewrite to boot.On 7/19/08, André Warnier <aw@xxxxxxxxxx> wrote:jamanbo jamanbo wrote:If I go to a.proxy.com which is proxying a.site.com then I expect that a good browser will refuse to accept cookies in the .site.com domain. But if it were possibly to configure the proxy so that the browser thought it was in the .site.com domain even though the url was .proxy.com (which is what I thought a proxy essentially did) then the cookies would be accepted, and people keep _suggesting_ to me that this is possible (although nobody ever goes so far as to tell me what I need to do with my config to achieve this!). Can you put this question to rest for me once and for all?Being sorry to stay in the domain of generalities, and not giving you a receipe, I would nevertheless think that if a proxy were to not pass unchanged the cookie headers from sites it proxies, then all these corporate users sitting behind proxying systems would never be able to buy a book from Amazon, would they ? But I believe they can, can't they ? (In fact, I am quite sure of that, because our own applications rely on cookies, and they are used constantly by corporate users sitting behind proxies). So I would think that the *normal* behaviour of a browser and of a proxy server, should be to *not* play around with cookies. Contrarily to what you say above, I would thus imagine that a browser that accesses a.site.com, even through a proxy, should accept a response (even physically from the proxy) containing a cookie for "a.site.com" or ".site.com", if such was the URL it requested in the first place. If it does not in some cases, then there must be some non-default parameter somewhere that prevents it. In other words also, this would tend to indicate that server responses containing "Set-Cookie" headers should not be cacheable by proxies, because the cookie header may be different each time, even accessing the same URL. (Or, maybe the content is cached, but the HTTP headers cannot be). Or maybe there is some sophisticated and obscure logic behind this stuff that I fail to grasp.I think the confusion is between an network proxy server and a Web "reverse" proxy server. A network proxy server handles NAT (Network Address Translation). A company internally uses private IP addresses (e.g. 10.*.*.*). All Internet traffic from these internal addresses use a network proxy server to reach the Internet. The proxy server changes the originating IP Addresses on the outbound packets from the internal network IP address to the proxy's Internet IP address. Responses from the Internet server are received by the proxy server and changed again to be sent to the originating computer on the internal network. The browser uses the Internet domain name so Cookies are not affected. A Web "reverse" proxy server handles multiple software applications appearing as a single server. The applications can be found on multiple ports on one server or on multiple hardware servers. Visitor traffic to several applications goes to one IP Address. The Web server at that IP Address decides where the request should be sent distinguishing based on the server name (using Virtual Servers) or the path (using Rewrites). If the applications use Cookies, the application Cookies must be rewritten by the Web proxy server because the browsers use the server name of the Web proxy server, not the application servers. 1. The browser requests http://myapp.example.com. 2. The Web proxy server myapp.example.com sends the request to myInternalApplicationServer.example.org. 3. The myInternalApplicationServer.example.org sends a response with a Cookie for myInternalApplicationServer.example.org to the Web proxy server. 4. The Web proxy server changes the Cookie from myInternalApplicationServer.example.org to myapp.example.com. 5. The browser receives the Cookie for myapp.example.com and send the Cookie with future requests to the Web proxy server. 6. The Web proxy server sends the incoming Cookies with the request to the application server as in #2. (Depending on security, the incoming Cookies may need to be changed to match the receiving server.) 7. GOTO #3. Deciding the type of proxy server being used may be confusing. An Internet request for an internal server can be handled with either type depending on the gateway server. - Network proxy: The gateway uses firewall software for NAT -- all requests for the internal server are sent to the internal server. The internal server sends Cookies using its Internet name. - Web proxy: The gateway is a Web server. Internal application servers do not use Internet names so the gateway must translate URLs and Cookies. -- The specification in the OP was how to Web proxy requests: 1. Server receives request for http://www.example.com/amazon/... 2. Server passes request to http://www.amazon.com/... 3. Server translates response from amazon so the visitor receives Cookies from .example.com. 4. Future requests are translated so the Web proxy server (www.example.com) sends the requests including Cookies to amazon.com. Read http://httpd.apache.org/docs/2.0/mod/mod_proxy.html Read the sections applying to "reverse" proxies. Ignore "forward" proxying because that process is not transparent -- the client computer must be configured to use a forward proxy. I once had difficulty with ProxyPass and switched to using Rewrites so I would handle this with something like: RewriteEngine On RewriteRule ^/amazon/(.*)$ http://www.amazon.com/$1 [P] ProxyPassReverseCookieDomain amazon.com example.com ProxyPassReverse /amazon/ http://www.amazon.com/ This should handle Cookies and handle removing/adding "/amazon" in the path. We have not discussed changing links in pages from amazon.com to use example.com. This simple often-needed functionality has been ignored by the Apache httpd project. (This functionality was included in a servlet I wrote in 1999.) Research "mod_proxy_html". Does this answer your question? solprovider
But there is still a third case, no ?I will pick this up in another thread, not to totally clobber the OP's question though.
André --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|