Hi,

Stefan Lambrev wrote:[...][...][...]

As I said I have some problems with pound and rewrites done by apache.

Here is my pound.conf:

ListenHTTPS
  Address 0.0.0.0
  Port    443
  Cert    "/server.pem"
  Ciphers "ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM:-SSLv2"
  NoHTTPS11 0
  Err503 "/usr/local/etc/pound/error503.html"
  LogLevel 2
End

ListenHTTP
  Address 0.0.0.0
  Port    80
  RewriteLocation 1
  Err503 "/usr/local/etc/pound/error503.html"
  LogLevel 2
End

Service
    URL ".*/apps/*"

    BackEnd
        Address 192.168.1.13
        Port    8080
        TimeOut 3000
    End
End

Service

    BackEnd
        Address test4.test.net (192.168.1.4)
        Port    9080
        TimeOut 3000
    End

End

The pound runs on 192.168.1.6 in this case.
And here is what GET yield:

shell# GET -d -S -U -s http:/test6.test.net/TEST

GET http://test6.test.net/TEST -->
301 Moved Permanently
GET http://test6.test.net:9080/TEST/
--> 500 Can't connect to 
test6.test.net:9080 (connect: Invalid argument)

After playing a little by mistake I put on test6 (where pound runs) in 
/etc/hosts
192.168.1.4     test6.test.net (should be test4) and restarted pound.

And viola everything starts to work as expected.

Of course this is not a solution because I have more then a single 
backend in production and I can NOT put the same line for all of them,
also it will confuse other applications.

I also changed "Address 0.0.0.0" to "Address 192.168.1.6", but this does 
not change a thing.

Please help Robert :)
[...]

Stefan Lambrev wrote:[...][...]
>>> Normally this is handled by the RewriteLocation directive - make
sure it
>>> is not set to 0. Also check that the redirect is indeed to the
back-end
>>> (or to a host that resolves to the same address).
>>>   [...][...]

This is not pound's fault, this is an error in your apache 
configuration. Pound will never issue a 301, your backend server did that.

On Mon, 2007-06-04 at 16:55 +0300, Stefan Lambrev wrote:[...]

1. Please don't use 0.0.0.0 as a listening address - it may effectively
disable the rewriting mechanism.

2. Put only numeric addresses in the config file to make sure it's not a
DNS or hosts problem

3. Try GET http://192.168.1.6/TEST to
test.

Once the above works start playing with symbolic names and so on.[...]

Hi,

Robert Segall wrote:[...][...][...]
Ok this is replaced with local IP[...]
This is changed to IPs (the initial state was with IP I changed it to 
hostname during tests)[...]
Ok it works now with IP, but works ok only with IP :)

I have the feeling that pound is using DNS queries in its rewrite mechanism.

Here is list of what works and what do not work.
1) pound listen on 1.2.3.4, remote GET http://1.2.3.4/SOMEDIR works ok.
and I got redirect to http://1.2.3.4/SOMEDIR/

2) if I add some.domain.tld in my remote /etc/hosts file to point to 1.2.3.4
and then GET http://some.domain.tld/SOMEDIR then I
got redirected to
http://some.domain.tld:9081/SOMEDIR/
- 9081 is the port of the backend.

3) if I add some.domain.tld to point 1.2.3.4 on pound server's /etc/hosts
then GET http://some.domain.tld/SOMEDIR got
redirected as expected to:
http://some.domain.tld/SOMEDIR/

So when pound checks what to rewrite it makes some dns queries and if 
the host
does not resolve to the IP that pound listen, rewrite just does not work ?
Am I right ?

P.S. I hope this is easy to reproduce - you need just 3 machines: a 
back-end that listen on weird port, pound server
and place from where to launch requests.

For my tests I played with pound 2.3.2. and apache 1.3.37
[...]

On Tue, 2007-06-05 at 12:25 +0300, Stefan Lambrev wrote:[...]

The remote name resolution is irrelevant. What does matter:

1. Pound needs to be able to resolve the address(es) it is to listen on

2. Pound needs to resolve the back-end addresses

3. Pound needs to be able to resolve the addresses in the redirect

While the first two are obvious, the third may be tricky: the redirects
are often to a host name (not a numeric address), and this name must be
resolvable. Failing that the rewriting mechanism cannot work.

Also note that the re-directions may be to different destinations,
depending on back-end type. Assume the request was to http://x.y.z/a and
the back-end is http://p.q.r on 9080 the reply may
be to:

http://x.y.z/a/
http://x.y.z:9080/a/
http://p.q.r/a/
http://p.q.r:9080/a/

all of which should be rewritten as http://x.y.z/a/ - you may need to
experiment with various settings to get it right.

I suggest using something like tcpwatch to see exactly what is returned
by the back-end.[...]

Hi,

Here is snip from tcpwatch (it sits between pound and backend):

Robert Segall wrote:[...][...]
==>GET /TEST HTTP/1.1
==>Host: 192.168.2.220
<==HTTP/1.1 301 Moved Permanently
<==Server: Apache
<==Location: http://192.168.2.220:9081/TEST/
[...]
==>GET /TEST HTTP/1.1
==>Host: goar.cmotd.com
<==HTTP/1.1 301 Moved Permanently
<==Location: http://goar.cmotd.com:9081/TEST/
<==Connection: close

and from pound's logs :
pound: gethostbyname(goar.cmotd.com): Unknown host
pound: 192.168.3.125 GET /TEST HTTP/1.1 - HTTP/1.1 301 Moved Permanently 
(goar.cmotd.com/- -> 192.168.2.220:81) 0.108 sec
[...]
==>GET /TEST HTTP/1.1
==>Host: goar.cmotd.com
<==HTTP/1.1 301 Moved Permanently
<==Location: http://goar.cmotd.com:9081/TEST
[...][...]
As you can see in variant 2) and 3) backend responds identical, but in 
variant 2 pound can't find the hostname
and the rewrite is not working.

and here is more interesting case where I use something that my dns can 
resolve:
boar.cmotd.com -> 192.168.3.112, but on the machine that create the GET 
request I put in /etc/hosts
boar.cmotd.com  -> 192.168.13.6 (pound hosts) and launched:

GET -d -S -U -s http://boar.cmotd.com/TEST
And what I got in response is:
GET http://boar.cmotd.com/TEST -->
301 Moved Permanently
GET http://boar.cmotd.com:9081/TEST/
--> 200 OK (this is OK only because 
the client here have direct access to the backend)

In this situation pound does not throw error message that can't find 
hostname.

==>GET /TEST HTTP/1.1
==>Host: boar.cmotd.com
<==HTTP/1.1 301 Moved Permanently
<==Location: http://boar.cmotd.com:9081/SENDMONEY/

So in all variants my backend response always with the same redirect, 
but pound react different,
depending on gethostbyname() responses ?
[...]

On Tue, 2007-06-05 at 15:36 +0300, Stefan Lambrev wrote:[...]

Yes.

To keep it simple: if you want redirect (or location) rewriting to work
make sure the host name that the redirection points to is resolvable.[...]

Hi Robert,

Robert Segall wrote:[...][...][...]
In my situation this rise a new problem.
If RewriteLocation works (e.g. no trailing slash problems, no wrong ports)
this screw one of my internal redirects.
My application detect if page (like login page) is requested using HTTP
and redirect to the same URL, but HTTPS.
Unfortunately pound rewrite the url and the redirect points again to http.

For example GET http://www.mydomain.tld/login redirect
to
https://www.mydomain.tld/login,
but pound rewrite it again to
http://www.mydomain.tld/login which
leads to unbreakable cycle.

Any ideas how to fix this?
[...]

On Wed, 2007-06-06 at 12:48 +0300, Stefan Lambrev wrote:[...]

Please read the RewriteLocation section in the man page. Basically you
want to set it to 0 for the above case.[...]

In the grand tradition of replying to my own posts, here's some more 
information, hopefully resembling an actual bug report.  My original 
report stands, but I would like to add the following:

I believe some regression was introduced between 2.3.2 and 2.4b.  The 
following script works fine in Safari under Pound 2.3.2, but when I 
switch to 2.4b, I get the errors I previously mentioned.

The source code of the test script is:
====
<?
if (isset($_GET['redirect'])) {
   header("Location: safari.php");
}

?>

<a href="http://www.geekisp.com/test/safari.php">HTTP,
no redirect</a> 
<br />
<a href="http://www.geekisp.com/test/safari.php?redirect=1">HTTP,

redirect</a> <br />
<a href="https://www.geekisp.com/test/safari.php">HTTPS,
no redirect</a> 
<br />
<a href="https://www.geekisp.com/test/safari.php?redirect=1">HTTPS,

redirect</a> <br />
====

Anecdotally, I thought the original problem was manifesting itself only 
with redirects, but all of the above links appear to exhibit it.

You're welcome to hit any of those URLs if you would like to see their 
behavior under 2.3.2.  Its not very interesting, though, since this is 
where it works!  I've taken 2.4b down in the interest of serving my 
customers, but I would be happy to gather more data as requested.

Can anyone else confirm that Safari errors under 2.4b with the simple 
script above?  Adjust for your hostname of course.

Regards,[...]

The pound homepage describes how you can filter based on IP rules.

We ran into a similar issue here, and we wrote a small ISAPI filter for 
IIS that restricts access (and in some cases expands access) based on 
the IP address.

James Evans wrote:[...]

Hi James,
[...]

This doesn't answer your questions directly, but we are using Apache in
front of Pound to handle IP-based and Basic authentication, logging and
static file caching.

HTH,

 Curro

This email message is intended only for the use of the named recipient.
Information contained in this email message and its attachments may be
privileged, confidential and protected from disclosure. If you are not the
intended recipient, please do not read, copy, use or disclose this
communication to others. Also please notify the sender by replying to this
message and then delete it from your system.

James Evans wrote:[...]

I'm guessing the pound machine is a linux machine? Then just use 
iptables or hosts.deny

iptables and hosts.deny don't restrict access to certain directories!
I think you must work on backends to do what you need.

Lorenzo