Hi Joe,
Thanks for your reply. No our clients arent proxies. However we are using
pound 1.9 version to make it to support dual stack.
Few additional questions
1) Does the latest version support wild card interfaces as in 1.9 version?
2) In Pound 2.4, why is there a break for TCP socket in get_host method as
shown below?
How does it support Dual-Stack?
/*
* Search for a host name, return the addrinfo for it
*/
int
get_host(char *const name, struct addrinfo *res)
{
struct addrinfo *chain, *ap;
int ret_val;
#ifdef HAVE_INET_NTOP
if((ret_val = getaddrinfo(name, NULL, NULL, &chain)) == 0) {
for(ap = chain; ap != NULL; ap = ap->ai_next)
if(ap->ai_socktype == SOCK_STREAM)
break;Thanks,
Raj
----- Original Message -----
From: Joe Gooch <[email protected]>
To: '[email protected]' <[email protected]>
Sent: Thu, 07 Mar 2013 20:34:02 +0530 (IST)
Subject: RE: [Pound Mailing List] Location comarision with backend address &
host
Sorry, 1.9 was released in 2005. So it’s more like 8 years old.:-D
Joe
From: Joe Gooch
Sent: Thursday, March 07, 2013 9:39 AM
To: '[email protected]'
Subject: RE: [Pound Mailing List] Location comarision with backend address &
host
Your clients are proxies?
Client 1.1.1.1 -> Pound 2.2.2.2 -> Backends 3.3.3.3 and 4.4.4.4
Client 1.1.1.1 contacts pound at 2.2.2.2, with url /
Pound 2.2.2.2 contacts Backend 3.3.3.3 with URL /
Backend 3.3.3.3 sends a redirect:
Location: http://3.3.3.3/mysite/
Pound compares said location header against the BACKEND addresses. Hey look,
backend 3.3.3.3 is trying to redirect to itself! But client 1.1.1.1 can’t
speak to 3.3.3.3. It’s speaking to 2.2.2.2.
Pound rewrites the location:
Location: http://2.2.2.2/mysite/
And sends it back to the client.
This behavior is controllable with config option RewriteLocation and
RewriteDestination in versions of code that aren’t already 4+ years out of date.
Joe
From: Raj Kishore1/CHN/TCS [mailto:[email protected]]
Sent: Thursday, March 07, 2013 9:04 AM
To:[email protected]
Subject: RE: [Pound Mailing List] Location comarision with backend address &
host
Hi,
When External Client sends a request, it is only going to be proxy address. Why
is there a condition to compare the location header address to that of backend
address list?
Please clarify!!
for(i = 0; i < grp->tot_pri; i++)
if(memcmp(&grp->backend_addr[i].addr.sin_addr, &addr.sin_addr,
sizeof(addr.sin_addr)) == 0
&& memcmp(&grp->backend_addr[i].addr.sin_port, &addr.sin_port,
sizeof(addr.sin_port)) == 0)
return 1;
return 0;
Thanks
Raj
----- Original Message -----
From: Joe Gooch <[email protected]>
To: '[email protected]' <[email protected]>
Sent: Wed, 06 Mar 2013 20:06:24 +0530 (IST)
Subject: RE: [Pound Mailing List] Location comarision with backend address &
host
is_be is used for location rewriting. If the backend throws a redirect, and
the address is one of our known backends, then we can rewrite the redirect to
point to the proxy address. (as you usually wouldn’t want the client to try to
hit the backend directly, and it’s even possible it can’t hit the backend
directly because it might be a private address)
Why would you want to remove this?
Joe
From: Raj Kishore1/CHN/TCS [mailto:[email protected]]
Sent: Wednesday, March 06, 2013 3:48 AM
To:[email protected]
Subject: [Pound Mailing List] Location comarision with backend address & host
Hi,
In pound 1.9 version, function "is_be" function in file svc.c is written to
find if a host is in our list of back-ends. Could anyone explain the need of
such comparision of the location address with list of backend address and with
to_host . What could be the effect in pound if this function is removed?
Comparision:-
if(memcmp(&to_host->sin_addr, &addr.sin_addr, sizeof(addr.sin_addr)) == 0
&& memcmp(&to_host->sin_port, &addr.sin_port, sizeof(addr.sin_port)) == 0)
return 1;
for(i = 0; i < grp->tot_pri; i++)
if(memcmp(&grp->backend_addr[i].addr.sin_addr, &addr.sin_addr,
sizeof(addr.sin_addr)) == 0
&& memcmp(&grp->backend_addr[i].addr.sin_port, &addr.sin_port,
sizeof(addr.sin_port)) == 0)
return 1;
return 0;
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
