Re: [EMAIL PROTECTED] Redirection
On 7/19/08, Alberto García Gómez <[EMAIL PROTECTED]> wrote:
> I have this URL
> http://www.server.com/index.php?article1.html
>
> and work like that
> http://www.server.com/?article1.html
>
> But I really really need this
> http://www.server.com/article1.html
>
> And I need to work like previous URL and I need to make the changes in
> .htaccess file
> PLEASE I had try everything and nothing work, somebody can help me please.
Am I missing something? The answer is your title. Just use
mod_rewrite to translate the old URLs to the new URLS or vice versa.
# Required for Rewrite
Options FollowSymLinks
RewriteEngine On
# Choose one or create potential infinite loop.
# Translate /article1.html -> /index.html?article1.html
RewriteRule ^/article1.html$ /index.html?article1.html [P]
# OR
# Translate ?article1.html -> /article1.html
RewriteCond %{QUERY_STRING} ^article1.html$
RewriteRule ^*$ /article1.html [P]
You could use [L] instead of [P] if you are certian that no proxy is
needed to find the file.
HTH,
solprovider
Re: [EMAIL PROTECTED] different kinds of proxies
On 7/19/08, André Warnier <[EMAIL PROTECTED]> wrote: > From a recent thread originally dedicated to find out if a proxy server can > be really "transparent", I'll first quote a summary from "solprovider". > > quote > > 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". > > unquote > > Now, I believe that there is still a third type of proxy, as follows : > > When I configure my browser to use "ourproxy.ourdomain.com:8000" as the > HTTP proxy for my browser, it means that independently of whatever NAT may > be effected by an internal router that connects my internal network to the > internet, something else is going on : > Whenever I type in my browser a URL like "http://www.amazon.com";, my > browser will not resolve "www.amazon.com" and send it a request like : > GET / HTTP/1.1 > Host: www.amazon.com > > Instead, my browser will send a request to "ourproxy.ourdomain.com:8000", > as follows : > GET http://www.amazon.com
Re: [EMAIL PROTECTED] Setting cookies from proxied backend
On 7/19/08, André Warnier <[EMAIL PROTECTED]> wrote: > I am not the ultimate specialist here, but I am interested, because I'd > like to make sure too. > > And there is still something that bothers me in the explanations above : > > I assume that what you mean by "accessing a site via a proxy" is this : > - your browser always uses URLs to "http://myproxy.mydomain.com"; > - but this proxy server, > - if the request is like > "http://myproxy.mydomain.com/amazon/item1";, issues a > request to "http://www.amazon.com/item1";, retrieves that page (and > associated cookies), and returns that page (and associated cookies) to the > browser > - if the request is like > "http://myproxy.mydomain.com/google/item1";, issues a > request to "http://www.google.com/item1";, retrieves that page (and > associated cookies), and returns that page (and associated cookies) to the > browser > - if the request is not like above, the proxy serves it from local pages > > And you would like that the cookies sent by the original sites, arrive to > the browser as set by the original site. In other words, you would like > that if "www.amazon.com" sets a cookie with a domain of "www.amazon.com" (or > ".amazon.com"), then that's how your browser should see it. Let's call > this alternative A. > > The alternative (apparently possible), would be that the proxy server > rewrites the cookies so that they all appear to originate from > "myproxy.mydomain.com" (or ".mydomain.com"). Let's call this alternative B. > > But as I see it, I see a problem with both options. > > Problem with alternative A : > The received cookie has a domain of ".amazon.com". > Thus, when your browser issues the next request to > "http://myproxy.mydomain.com/amazon/item2";, this cookie > will not be sent by the browser, because the domains don't match (and your > browser has no idea that this URL is ultimately destined for amazon). > > Problem with alternative B : > The received cookies all have a domain of ".mydomain.com". > Thus they will be sent by the browser for any subsequent request to > "http://myproxy.mydomain.com/amazon/*"; OR > "http://myproxy.mydomain.com/google/*";, because now the > domain matches always. > Now what if these two sites send a cookie with the same name ? > I mean : you visit > "http://myproxy.mydomain.com/amazon/item1"; and you receive > a cookie named "private-info" from the domain "mydomain.com". Then you visit > "http://myproxy.mydomain.com/google/item2"; and you receive > a cookie named "private-info" from the domain "mydomain.com". > The second cookie would overwrite the first one. > Then you access again > "http://myproxy.mydomain.com/amazon/item1";, and your > browser would attach the cookie "private-info" originally from the google > site (or the "JSESSIONID" cookie from Tomcat e.g.). > That does not sound right, does it ? > > At any rate, it seems to me that you'd have to do some more juggling to > keep things working as planned, no ? > At the very least, you would have to also rename the received cookie at the > proxy level (e.g. prefix the name with some original site-id) before sending > it to the browser, and vice-versa when the browser re-sends the cookie, > rename it again (strip the prefix) before sending it to the original site. > Plus, even so, when your browser accesses either > "http://myproxy.mydomain.com/amazon/item1"; or > "http://myproxy.mydomain.com/google/item1";, it will send > both cookies, because the domain ".mydomain.com" matches in both cases. So > the proy should also be smart enough to strip off the cookie that does not > belong to the real destination site. > > Is that thing smart enough to do that ? > Or am I not smart enough to see an obvious solution ? > André Alternative A has the additional problem that browsers reject Cookies when the domain specified does not match the originating server. Yes, the Cookie would not be returned to the originating server because the Cookie is for a different domain, but the Cookie would not even be saved because that would create security issues. Your concerns for Alternative B are valid, but the solution is different than proposed. You do not rename Cookies to avoid conflicts, just set the path parameter. Alternative B is that one proxy server accesses multiple applications (or other websites) that set Cookies with the same name and different information. This is very common as many websites use Google's visitor tracking. (Check your browser's stored Cookies for the names "__utma" and "__utmz" for many websites.) With proper care, this is not a problem. Cookies include a path parameter. The cookie for http://www.example.com/google/... should have the path "/google". The cookie for http://www.example.com/amazon/...should have the path "/amazon". A Web reverse proxy using paths to specify which application handles the request should use the ProxyPassReverseCookiePath directive to translate the outbound Cookies. Inbound tran
Re: [EMAIL PROTECTED] Setting cookies from proxied backend
On 7/19/08, jamanbo jamanbo <[EMAIL PROTECTED]> wrote: > > 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. > > This is how I have come to understand the process too. > > It is step 4 I would like to change though. In my case I need cookies > to continue to be set for .example.ORG and not modify them to > .example.COM. Whilst there seems to be no difficulty in doing this in > Apache (you simply omit the ProxyPassReverseCookieDomain), I am > thinking that it amounts to a cross domain cookie injection "attack" > and that no half-decent browser would accept the cookies. > > What I have been asking for most of this last week is whether or not > it is possible for me to visit a site via a proxy yet continue to have > cookies set as though I had visited the site directly. Those who said > "yes you can" also generally said something like "thats the way > proxies work". I just want to make absolutely certain that this was > just a misunderstanding and that what they were really saying was that > the cookies can be set, but only by translating them into the proxy > domain ... otherwise I have made some rash claims about how I was > going to prove a concept of mine rapidly by using a proxy, and will > have to make an embarrassing climb down in work on Monday :S I think you understand. Browsers should discard Cookies not from the originating server, i.e. example.com cannot set Cookies for example.org. Servers can only set Cookies for themselves and higher domains containing at least a prefixed and one internal dot ".example.com". (This is dangerous when the domain is ".com.us" or some other country codes when two levels does not determine ownership.) There are workarounds when you control both domains. Single-sign-on solutions often redirect several times using different URLs to set Cookies for multiple domains. The process might be: 1. Send login information to first domain. 2. First domain's login redirects browser to master domain. 3. Master domain checks for Cookie from master domain. If master domain Cookie is not found, create session and Cookie. 4. Redirect to first domain with session ID in URL. 5. First domain checks with master domain that session is valid. 6. First domain sets Cookie based on new URL Step 5 in this process requires the first domain is able to verify the master domain session using a backend process. The first domain can maintain its session independent of the master session after this process completes once. Again, this requires that either you control both domains or the master domain provides an API for single-sign-on. This probably does not apply to your situation. Using a Web "reverse" proxy, the answer is that creating a Cookie for amazon.com requires the browser to receive a page from a server named *.amazon.com. Using something similar to a cross-site attack could handle this (e.g. opening www.amazon.com in a frame), but is highly discouraged. If you want people on an internal network to be able to access amazon.com and receive Cookies from amazon.com, a Web reverse proxy is not the solution. The two solutions are: - A forward proxy could be used. This requires clients to be configured to use the forward proxy. - Any NAT firewall should handle this transparently. No client configuration is necessary; just configure routing between networks to use the NAT firewall as the gateway.. Apache httpd can handle both forward and reverse proxying, but is not a NAT firewall. Standard *nix software (e.g. iptables and PF) can be NAT firewalls. (Using Microsoft software for networking may be a criminal offense and should lead to a justified termination.) solprovider - The official User-To-User support forum of the Apache HTTP Server Project. See http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: [EMAIL PROTECTED] " from the digest: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED] Setting cookies from proxied backend
jamanbo jamanbo wrote: 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. This is how I have come to understand the process too. It is step 4 I would like to change though. In my case I need cookies to continue to be set for .example.ORG and not modify them to .example.COM. Whilst there seems to be no difficulty in doing this in Apache (you simply omit the ProxyPassReverseCookieDomain), I am thinking that it amounts to a cross domain cookie injection "attack" and that no half-decent browser would accept the cookies. What I have been asking for most of this last week is whether or not it is possible for me to visit a site via a proxy yet continue to have cookies set as though I had visited the site directly. Those who said "yes you can" also generally said something like "thats the way proxies work". I just want to make absolutely certain that this was just a misunderstanding and that what they were really saying was that the cookies can be set, but only by translating them into the proxy domain ... otherwise I have made some rash claims about how I was going to prove a concept of mine rapidly by using a proxy, and will have to make an embarrassing climb down in work on Monday :S I am not the ultimate specialist here, but I am interested, because I'd like to make sure too. And there is still something that bothers me in the explanations above : I assume that what you mean by "accessing a site via a proxy" is this : - your browser always uses URLs to "http://myproxy.mydomain.com"; - but this proxy server, - if the request is like "http://myproxy.mydomain.com/amazon/item1";, issues a request to "http://www.amazon.com/item1";, retrieves that page (and associated cookies), and returns that page (and associated cookies) to the browser - if the request is like "http://myproxy.mydomain.com/google/item1";, issues a request to "http://www.google.com/item1";, retrieves that page (and associated cookies), and returns that page (and associated cookies) to the browser - if the request is not like above, the proxy serves it from local pages And you would like that the cookies sent by the original sites, arrive to the browser as set by the original site. In other words, you would like that if "www.amazon.com" sets a cookie with a domain of "www.amazon.com" (or ".amazon.com"), then that's how your browser should see it. Let's call this alternative A. The alternative (apparently possible), would be that the proxy server rewrites the cookies so that they all appear to originate from "myproxy.mydomain.com" (or ".mydomain.com"). Let's call this alternative B. But as I see it, I see a problem with both options. Problem with alternative A : The received cookie has a domain of ".amazon.com". Thus, when your browser issues the next request to "http://myproxy.mydomain.com/amazon/item2";, this cookie will not be sent by the browser, because the domains don't match (and your browser has no idea that this URL is ultimately destined for amazon). Problem with alternative B : The received cookies all have a domain of ".mydomain.com". Thus they will be sent by the browser for any subsequent request to "http://myproxy.mydomain.com/amazon/*"; OR "http://myproxy.mydomain.com/google/*";, because now the domain matches always. Now what if these two sites send a cookie with the same name ? I mean : you visit "http://myproxy.mydomain.com/amazon/item1"; and you receive a cookie named "private-info" from the domain "mydomain.com". Then you visit "http://myproxy.mydomain.com/google/item2"; and you receive a cookie named "private-info" from the domain "mydomain.com". The second cookie would overwrite the first one. Then you access again "http://myproxy.mydomain.com/amazon/item1";, and your browser would attach the cookie "private-info" originally from the google site (or the "JSESSIONID" cookie from Tomcat e.g.). That does not sound right, does it ? At any rate, it seems to me that you'd have to do some more juggling to keep things working as planned, no ? At the very least, you would have to also rename the received
Re: [EMAIL PROTECTED] Setting cookies from proxied backend
> 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. This is how I have come to understand the process too. It is step 4 I would like to change though. In my case I need cookies to continue to be set for .example.ORG and not modify them to .example.COM. Whilst there seems to be no difficulty in doing this in Apache (you simply omit the ProxyPassReverseCookieDomain), I am thinking that it amounts to a cross domain cookie injection "attack" and that no half-decent browser would accept the cookies. What I have been asking for most of this last week is whether or not it is possible for me to visit a site via a proxy yet continue to have cookies set as though I had visited the site directly. Those who said "yes you can" also generally said something like "thats the way proxies work". I just want to make absolutely certain that this was just a misunderstanding and that what they were really saying was that the cookies can be set, but only by translating them into the proxy domain ... otherwise I have made some rash claims about how I was going to prove a concept of mine rapidly by using a proxy, and will have to make an embarrassing climb down in work on Monday :S - The official User-To-User support forum of the Apache HTTP Server Project. See http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: [EMAIL PROTECTED] " from the digest: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED] different kinds of proxies
Hi. From a recent thread originally dedicated to find out if a proxy server can be really "transparent", I'll first quote a summary from "solprovider". quote 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". unquote Now, I believe that there is still a third type of proxy, as follows : When I configure my browser to use "ourproxy.ourdomain.com:8000" as the HTTP proxy for my browser, it means that independently of whatever NAT may be effected by an internal router that connects my internal network to the internet, something else is going on : Whenever I type in my browser a URL like "http://www.amazon.com";, my browser will not resolve "www.amazon.com" and send it a request like : GET / HTTP/1.1 Host: www.amazon.com ... Instead, my browser will send a request to "ourproxy.ourdomain.com:8000", as follows : GET http://www.amazon.com HTTP/1.1 Host: www.amazon.com ... The server at "ourproxy.ourdomain.com:8000" will then look up in his page cache, to see if it already has this page from a previous access. Then it will either return this cached page, or retrieve the page anew from "www.amazon.com", cache it (maybe) and del
[EMAIL PROTECTED] Redirection
I have this URL http://www.server.com/index.php?article1.html and work like that http://www.server.com/?article1.html But I really really need this http://www.server.com/article1.html And I need to work like previous URL and I need to make the changes in .htaccess file PLEASE I had try everything and nothing work, somebody can help me please. - The official User-To-User support forum of the Apache HTTP Server Project. See http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: [EMAIL PROTECTED] " from the digest: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED] Setting cookies from proxied backend
[EMAIL PROTECTED] wrote: On 7/19/08, André Warnier <[EMAIL PROTECTED]> 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 transl
Re: [EMAIL PROTECTED] Setting cookies from proxied backend
On 7/19/08, André Warnier <[EMAIL PROTECTED]> 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 receiv
Re: [EMAIL PROTECTED] Setting cookies from proxied backend
jamanbo jamanbo wrote: Thank you both for the information. I am still confused on the fundamental issue though. Is it possible for a proxy to be effectively invisible? I keep getting different answers from different people. 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. - The official User-To-User support forum of the Apache HTTP Server Project. See http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: [EMAIL PROTECTED] " from the digest: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED] Setting cookies from proxied backend
Thank you both for the information. I am still confused on the fundamental issue though. Is it possible for a proxy to be effectively invisible? I keep getting different answers from different people. 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? Thanks. - The official User-To-User support forum of the Apache HTTP Server Project. See http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: [EMAIL PROTECTED] " from the digest: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED] apache load balance very uneven
Hi. I know next to nothing about load balancing per se, so this will be a very naive question related to the data below : does it matter ? I mean, I can see that the load appears to be uneven, but the grand total seems to be about 10% of the available cpu time. So do you really care if one instance is using 4% and another 0.4% if there is still 90% available in total ? I am also wondering if what is shown down there is not just this phenomenon : whenever the load balancer has to decide to which back-end to pass a request, I suppose it checks first which ones are already busy. Since in this case the total load is light and most of them are always free, it might just take the first of the list, which then ends up more used than the others. No ? André fernando castano wrote: Hi all, I'm new to apache. I am experiencing a problem with apache load balancer. I configured the load balancer across 10 app servers (glassfish domains), but when I see the way the cookies (and load) are distributed I see a very uneven distribution. Here is my proxy configuration: [EMAIL PROTECTED] more proxy_cluster.conf # configuration for clustering more then one glassfish ProxyPass / balancer://cluster/ stickysession=JSESSIONID nofailover=Off ProxyPassReverse / http://kenstgapp01:8080 ProxyPassReverse / http://kenstgapp01:8280 ProxyPassReverse / http://kenstgapp01:8380 ProxyPassReverse / http://kenstgapp01:8480 ProxyPassReverse / http://kenstgapp01:8580 ProxyPassReverse / http://kenstgapp01:8780 ProxyPassReverse / http://kenstgapp01:8880 ProxyPassReverse / http://kenstgapp01:8980 ProxyPassReverse / http://kenstgapp01:9080 ProxyPassReverse / http://kenstgapp01:9180 BalancerMember http://kenstgapp01:8080 route=kenstgapp01_8080 loadfactor=1 BalancerMember http://kenstgapp01:8280 route=kenstgapp01_8280 loadfactor=1 BalancerMember http://kenstgapp01:8380 route=kenstgapp01_8380 loadfactor=1 BalancerMember http://kenstgapp01:8480 route=kenstgapp01_8480 loadfactor=1 BalancerMember http://kenstgapp01:8580 route=kenstgapp01_8580 loadfactor=1 BalancerMember http://kenstgapp01:8780 route=kenstgapp01_8780 loadfactor=1 BalancerMember http://kenstgapp01:8880 route=kenstgapp01_8880 loadfactor=1 BalancerMember http://kenstgapp01:8980 route=kenstgapp01_8980 loadfactor=1 BalancerMember http://kenstgapp01:9080 route=kenstgapp01_9080 loadfactor=1 BalancerMember http://kenstgapp01:9180 route=kenstgapp01_9180 loadfactor=1 [EMAIL PROTECTED] And here is how the load gets distributed across jmeter 10 clients: as you can see, only 7 of the jvms get work, and among them the amount of work they do is very uneven (second to last entry in each row is % of cpu used by the process). These domains are exactly the same. I've checked the cookie distribution and reflects the load distribution (uneven). If I increase clients I eventually get work in all jvms (still uneven), and that just proves that all jvms can be routed thru apache load balancer. I am generating load with jmeter. Any hints of what am I doing wrong? how to fix it? PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 1388 root 3338M 3257M sleep00 9:08:45 6.5% java/89 1414 root 3332M 3253M cpu2800 7:32:01 4.2% java/92 1417 root M 3253M cpu9 00 7:14:39 2.3% java/96 1424 root 3332M 3254M cpu1200 7:03:12 2.2% java/89 1420 root 3332M 3254M cpu6 00 7:35:40 2.1% java/89 1411 root M 3253M cpu2900 7:31:31 1.9% java/87 3461 webservd 40M 32M sleep00 0:00:03 0.3% httpd/1 3460 webservd 36M 26M sleep00 0:00:03 0.3% httpd/1 3462 webservd 36M 26M sleep00 0:00:03 0.3% httpd/1 3457 webservd 32M 27M cpu2400 0:00:02 0.3% httpd/1 1423 root M 3256M sleep00 7:00:01 0.2% java/88 3348 webservd 40M 32M sleep00 0:00:04 0.2% httpd/1 995 root 3536K 3072K sleep 100- 0:00:46 0.1% cpustat/33 1360 webservd 43M 35M sleep00 0:00:14 0.1% httpd/1 1337 webservd 43M 35M sleep00 0:00:13 0.1% httpd/1 3559 webservd 13M 11M cpu2000 0:00:00 0.1% hgwebdir.cgi/1 883 root 3848K 3832K cpu2500 0:00:13 0.1% prstat/1 1011 webservd 43M 36M sleep00 0:00:15 0.1% httpd/1 77 webservd 9016K 7832K sleep00 0:16:18 0.1% memcached/1 Total: 166 processes, 1525 lwps, load averages: 10.00, 10.20, 10.03 TIA, fdo - The official User-To-User support forum of the Apache HTTP Server Project. See http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: [EMAIL PROTECTED] " from the digest: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - The official User-To-User
