Setting cookies from proxied backend

[jamanbo jamanbo]

I've been asking about this for a couple of days now on #apache so
apologies if you're tired of it before even reading any further.

My question is Is it possible to set up an Apache proxy of another
server in such a way that the proxy is invisible, in terms of cookies
at least? I.e. when I visit my proxy I want cookies from the backend
to get set exactly as if I had visited the backend directly
(by-passing the proxy).

I've been using a test configuration which I will show below. I picked
two big sites to test on. They appear to have been lucky choices as
they seem to exhibit different behaviour.

In the first case, I proxy www.espn.go.com and it appears that (some)
cookies from that site get set when I visit my proxy.

However in the second case, when I proxy www.amazon.com and visit my
proxy, I don't see any cookies (although the headers do contain
Set-Cookies).

Can somebody tell me if I am trying to do something impossible. Will
browser security features prevent cookies for www.espn.go.com being
set when I visit localhost:3333/espn? Or is my set up just wrong?

This is the test config if you want to try it:

Listen 3333
<VirtualHost *:3333>
ServerName localhost
DocumentRoot /var/www/revoxy

ProxyPreserveHost On
<proxy>
Order deny,allow
Allow from all
</proxy>

# Cookies from espn get set
<LocationMatch /espn/>
ProxyPass http://www.espn.go.com/
ProxyPassReverse /
# ProxyPassReverseCookieDomain espn.go.com localhost
</LocationMatch>

# Cookies from amazon don't get set
<LocationMatch /amazon/>
ProxyPass http://www.amazon.com/
ProxyPassReverse /
# ProxyPassReverseCookieDomain amazon.com localhost
</LocationMatch>
</VirtualHost>

Desperatley awaiting your advice,
JMBO!

---------------------------------------------------------------------
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-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org

[s***@apache.org]

Post by jamanbo jamanbo
My question is Is it possible to set up an Apache proxy of another
server in such a way that the proxy is invisible, in terms of cookies
at least? I.e. when I visit my proxy I want cookies from the backend
to get set exactly as if I had visited the backend directly
(by-passing the proxy).
I've been using a test configuration which I will show below. I picked
two big sites to test on. They appear to have been lucky choices as
they seem to exhibit different behaviour.
In the first case, I proxy www.espn.go.com and it appears that (some)
cookies from that site get set when I visit my proxy.
However in the second case, when I proxy www.amazon.com and visit my
proxy, I don't see any cookies (although the headers do contain
Set-Cookies).
Can somebody tell me if I am trying to do something impossible. Will
browser security features prevent cookies for www.espn.go.com being
set when I visit localhost:3333/espn? Or is my set up just wrong?
Listen 3333
<VirtualHost *:3333>
ServerName localhost
DocumentRoot /var/www/revoxy
ProxyPreserveHost On
<proxy>
Order deny,allow
Allow from all
</proxy>
# Cookies from espn get set
<LocationMatch /espn/>
ProxyPass http://www.espn.go.com/
ProxyPassReverse /
# ProxyPassReverseCookieDomain espn.go.com localhost
</LocationMatch>
# Cookies from amazon don't get set
<LocationMatch /amazon/>
ProxyPass http://www.amazon.com/
ProxyPassReverse /
# ProxyPassReverseCookieDomain amazon.com localhost
</LocationMatch>
</VirtualHost>
Desperatley awaiting your advice,
JMBO!

Cookies are set for the parent domain part of the server name. The
Cookie for "espn.example.com" is set at ".example.com".

Cookies cannot be set at the TLD level. Default domain no-name servers
("example.com") cannot use Cookies because the Cookie would be set at
the ".com" TLD. This may be the problem in your second example.

"localhost" should not work (although I have not tested lately). You
should configure a server name for testing. If httpd is responding to
all requests without virtual servers, you can configure the server
name in hosts (Windows) or resolv.conf (*nix).

I use the following in a virtual server configuration to proxy to an
application server firewalled from the Internet and runnng on port
8000 on the same hardware server. I use RewriteRule instead of
ProxyPass to pass incoming requests to the application server.
ProxyPassReverseCookieDomain 127.0.0.1 www.example.com
ProxyPassReverse / http://10.1.1.1:8000/
The application sends Cookies as 127.0.0.1. The first line translates
the Cookies to be from www.example.com. Browsers will save the Cookie
at the next level (".example.com") and send the Cookie with every
request to *.example.com. A server name at the same level must be
specified. Requests to "example.com" and
"server.subdomain.example.com" will not include the Cookie.

HTH,
solprovider

---------------------------------------------------------------------
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-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org

[André Warnier]

Hi.

First, I found a thread which might provide some useful information for
the original poster :

http://www.theserverside.com/patterns/thread.tss?thread_id=31258

Second,
[...]

Rescpectfully, I believe there are several inaccuracies in the
explanation given by solprovider, and this might induce the OP in error.
The notes below represent my own understanding of the matter, based on
http://www.w3.org/Protocols/rfc2109/rfc2109
and
http://en.wikipedia.org/wiki/HTTP_cookie#Implementation
Please correct me if I am wrong.

Post by s***@apache.org
Cookies are set for the parent domain part of the server name. The
Cookie for "espn.example.com" is set at".example.com".

The server "espn.example.com" can technically (try to) set a cookie for
whatever domain it chooses, via a "Set-Cookie" header. By default (when
not specified), the cookie domain is understood as being the domain that
exactly matches the server's FQDN (fully-qualified domain name, like
"a.example.com").

Now whether the browser accepts it is another story.

A browser respectful of the specification would only accept a cookie
from a server, if the server's own domain "belongs to" (is a sub-domain
of) the cookie domain.
For example, from a server known as "a.b.c.example.com", a browser will
accept a cookie for the domain "a.b.c.example.com" or ".b.c.example.com"
or ".c.example.com" or ".example.com" (but not for ".com" because that
domain does not contain at least two dots).

(The reason for that is that it is considered unsafe that a server
"www.kgb.ru.gov" should be able to set a cookie for the server
"www.cia.us.gov" for instance).

Post by s***@apache.org
Cookies cannot be set at the TLD level.

True in a way, see above, but only because the browser should not accept
a cookie for a domain that does not contain at least 2 dots.

Default domain no-name servers

Post by s***@apache.org
("example.com") cannot use Cookies because the Cookie would be set at
the ".com" TLD.

The server "example.com" can set a cookie for ".example.com".

[...]
Browsers will save the Cookie

Post by s***@apache.org
at the next level (".example.com") and send the Cookie with every
request to *.example.com. A server name at the same level must be
specified. Requests to "example.com" and
"server.subdomain.example.com" will not include the Cookie.

The browser will save the cookie with the domain exactly as specified in
the cookie, it this is valid (iow the domain of the cookie contains at
least 2 dots, and the server issuing the cookie is a member of that domain).

A cookie set for ".example.com" will be sent by the browser with any
request to "a.b.c.example.com", or ".b.c.example.com", or
".c.example.com" or ".example.com".
A cookie set for ".c.example.com" will be sent with every request to a
server "a.b.c.example.com" or ".b.c.example.com" or ".c.example.com",
but not for ".example.com" not for "d.example.com" e.g.

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-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org

[s***@apache.org]

Thank you for clarifying.
- I forgot to mention the Set-Cookie domain must match the suffix of
the originating host.
- Neither of us mentioned that IP Addresses are exempt from partial
domain matching. IP Addresses are allowed as the Cookie domain for
exact matches.
- We had difficulty receiving Cookies for c.b.a.com set by b.a.com at
the .a.com level during the last decade (1998?). Hopefully all modern
browsers work as specified in the RFC. I should have marked this
information as suggestive for testing rather than definitive.

"The server "example.com" can set a cookie for ".example.com"."
This should be inaccurate because ".example.com" is not a suffix of
the originating server. Server "example.com" may be able to set
Cookies for itself -- the RFC suggests the server name is used if no
Domain parameter is specified in Set-Coookie:
"Domain Defaults to the request-host. (Note that there is no dot
at the beginning of request-host.)"
The two-dots rule only applies to Domain parameters. I have not tested.

solprovider

First, I found a thread which might provide some useful information for the
http://www.theserverside.com/patterns/thread.tss?thread_id=31258
Second,
Rescpectfully, I believe there are several inaccuracies in the explanation
given by solprovider, and this might induce the OP in error.
The notes below represent my own understanding of the matter, based on
http://www.w3.org/Protocols/rfc2109/rfc2109
and
http://en.wikipedia.org/wiki/HTTP_cookie#Implementation
Please correct me if I am wrong.

Post by s***@apache.org
Cookies are set for the parent domain part of the server name. The
Cookie for "espn.example.com" is set at".example.com".

The server "espn.example.com" can technically (try to) set a cookie for
whatever domain it chooses, via a "Set-Cookie" header. By default (when not
specified), the cookie domain is understood as being the domain that exactly
matches the server's FQDN (fully-qualified domain name, like
"a.example.com").
Now whether the browser accepts it is another story.
A browser respectful of the specification would only accept a cookie from a
server, if the server's own domain "belongs to" (is a sub-domain of) the
cookie domain.
For example, from a server known as "a.b.c.example.com", a browser will
accept a cookie for the domain "a.b.c.example.com" or ".b.c.example.com" or
".c.example.com" or ".example.com" (but not for ".com" because that domain
does not contain at least two dots).
(The reason for that is that it is considered unsafe that a server
"www.kgb.ru.gov" should be able to set a cookie for the server
"www.cia.us.gov" for instance).

Post by s***@apache.org
Cookies cannot be set at the TLD level.

True in a way, see above, but only because the browser should not accept a
cookie for a domain that does not contain at least 2 dots.
Default domain no-name servers

Post by s***@apache.org
("example.com") cannot use Cookies because the Cookie would be set at
the ".com" TLD.

The server "example.com" can set a cookie for ".example.com".
Browsers will save the Cookie

Post by s***@apache.org
at the next level (".example.com") and send the Cookie with every
request to *.example.com. A server name at the same level must be
specified. Requests to "example.com" and
"server.subdomain.example.com" will not include the Cookie.

The browser will save the cookie with the domain exactly as specified in
the cookie, it this is valid (iow the domain of the cookie contains at least
2 dots, and the server issuing the cookie is a member of that domain).
A cookie set for ".example.com" will be sent by the browser with any
request to "a.b.c.example.com", or ".b.c.example.com", or ".c.example.com"
or ".example.com".
A cookie set for ".c.example.com" will be sent with every request to a
server "a.b.c.example.com" or ".b.c.example.com" or ".c.example.com", but
not for ".example.c

[jamanbo jamanbo]

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 <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org

[André Warnier]

Post by jamanbo jamanbo
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 <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org

[s***@apache.org]

Post by André Warnier

Post by jamanbo jamanbo
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?

solprovi

[André Warnier]

Post by s***@apache.org

Post by André Warnier

Post by jamanbo jamanbo
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.
--
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
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

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.

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-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org

[Alberto García Gómez]

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 <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org

[s***@apache.org]

Post by Alberto García Gómez
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,
solprov

[Alberto García Gómez]

I had this conf in my httpd.conf, in the VirtualDirectory of one website:

RewriteEngine On
RewriteLogLevel 9
RewriteRule ^/.*\.html$ /index.php?$1 [L]
RewriteRule ^/.*\.htm$ /index.php?$1 [L]

And I need to create a .htaccess file to work identical. I had try but
nothing work :-(



---------------------------------------------------------------------
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-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org

[Eric Covener]

On Mon, Jul 28, 2008 at 5:52 PM, Alberto García Gómez

Post by s***@apache.org
RewriteEngine On
RewriteLogLevel 9
RewriteRule ^/.*\.html$ /index.php?$1 [L]
RewriteRule ^/.*\.htm$ /index.php?$1 [L]
And I need to create a .htaccess file to work identical. I had try but
nothing work :-(

Add an appropriate RewriteBase
Strip off "^/.*" from your rules
Figure out if you want to rewrite to "/index.php" or "index.php" (of
if this goes in documentroot, just drop the /)
--
Eric Covener
***@gmail.com

---------------------------------------------------------------------
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-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org

[Alberto García Gómez]

Please my friend, can you be more specifyc...I mean how the code will look.

Thanks and Regards.

----- Original Message -----
From: "Eric Covener" <***@gmail.com>
To: <***@httpd.apache.org>
Sent: Monday, July 28, 2008 7:40 PM
Subject: [***SPAM*** Score/Req: 18.0/5.0] Re: [***@httpd] .htaccess
Redirection


On Mon, Jul 28, 2008 at 5:52 PM, Alberto García Gómez

Post by s***@apache.org
RewriteEngine On
RewriteLogLevel 9
RewriteRule ^/.*\.html$ /index.php?$1 [L]
RewriteRule ^/.*\.htm$ /index.php?$1 [L]
And I need to create a .htaccess file to work identical. I had try but
nothing work :-(

Add an appropriate RewriteBase
Strip off "^/.*" from your rules
Figure out if you want to rewrite to "/index.php" or "index.php" (of
if this goes in documentroot, just drop the /)
--
Eric Covener
***@gmail.com

---------------------------------------------------------------------
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-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org




---------------------------------------------------------------------
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-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org

[jamanbo jamanbo]

Post by s***@apache.org
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 <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org

[André Warnier]

Post by jamanbo jamanbo

Post by s***@apache.org
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 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é



---------------------------------------------------------------------
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-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org

[s***@apache.org]

Post by André Warnier
I am not the ultimate specialist here, but I am interested, because I'd
like to make sure too.
- 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.
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).
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 translation should not be needed as browsers will
only send Cookies for the current path i.e.
http://www.example.com/amazon/... will not include Cooki

[s***@apache.org]

Post by jamanbo jamanbo

Post by s***@apache.org
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 <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org