/ Zope / Apsis / Pound Mailing List / Archive / 2006 / 2006-06 / URL Rewriting Issues with Pound Version 2 and OpenACS

[ << ] [ >> ]

[ Install / Compile Error on Suse 10.0: Missing ... ] [ Redirect from www\.(.+) to \1 / "Klaus ... ]

URL Rewriting Issues with Pound Version 2 and OpenACS
"Richard Hamilton" <ricky.hamilton(at)btopenworld.com>
2006-06-14 23:12:04 [ SNIP ]
Dear All,

I have Pound set up to reverse proxy from incoming on port 81 (for test
purposes) to a server listening on 8002. For the purposes of this test I am
only concerned with HTTP.

Using IE when I enter http://www.sitename.com:81, Pound does a great job of
passing the request to the backend that listens on port 8002, and the URL shown
in the address bar remains as entered (port 81). However, when I click on links
on the returned page (which are all relative links such as /home/images), the
address bar changes to reflect the port on which the server is listening (port
8002) - http://www.sitename.com:8002/home/contacts . In other words the browser
is now making the request direct to the server on port 8002 rather than through
Pound on port 81.

Puzzlingly, Mozilla does not do this. Mozilla continues to request the relative
urls using port 81, so clearly there is something that IE chooses to do in the
presence or absence of certain information that Mozilla does not do (I am
assuming that Pound does not pass the backend server port information to the
browser deliberately since that would seem to run counter to its intended
function).

In this post
(http://www.apsis.ch/pound/pound_list/archive/2004/2004-02/1075941729000) I see
that Gustav Neumann seems to have addressed this (or a closely related) issue
with his patches to version 1.4 of Pound. He seems to have added a parameter -
[LocationUrlRewrite 1] along with the following explanation:

"Many web-apps (in particular OpenACS) like to redirect http requests to
different urls on the same server..........When the backend (say host:8000)
makes a redirect to itself, the redirect should really point to the proxy
server."

OpenACS sets up many Aolserver request filters which trigger redirects based
upon a set of url structure assumptions and rules, however I don't know for
certain if thi is the issue. Could it be caused by Explorer's interpretation of
the current path from which to seek a relative url? Of one thing I can be
certain - the urls on the site are relative not absolute. I know this because
the reverse proxy works fine both when using Mozilla as the client, and also
when using another reverse proxy solution as an alternative to Pound.

I note that in the current (non beta) version of Pound the LocationUrlRewrite
parameter is not an option and I wondered if this means that I must track down
Gustav's patches and use v1.4, or whether there is something else that I can do
to prevent this happening.

If anyone has any ideas as to why when a request for a relative url is received
from Internet Explorer by Pound, the request is redirected by IE to port 8002
instead of using the port 81 connection already established, I would be most
grateful to hear about them.

Regards
Richard
Attachments:  
text.html text/html 4234 Bytes

Re: [Pound Mailing List] URL Rewriting Issues with Pound Version 2 and OpenACS
Janno Sannik <janno(at)foor.ee>
2006-06-15 11:59:27 [ SNIP ]
Have you tried playing with apache conf
printout from apache conf:

# ServerName gives the name and port that the server uses to identify 
itself.
# This can often be determined automatically, but we recommend you specify
# it explicitly to prevent problems during startup.
#
# If this is not set to valid DNS name for your host, server-generated
# redirections will not work.  See also the UseCanonicalName directive.
#
# If your host doesn't have a registered DNS name, enter its IP address 
here.
# You will have to access it by its address anyway, and this will make
# redirections work in a sensible way.
#
#ServerName www.example.com:80

#
# UseCanonicalName: Determines how Apache constructs self-referencing
# URLs and the SERVER_NAME and SERVER_PORT variables.
# When set "Off", Apache will use the Hostname and Port supplied
# by the client.  When set "On", Apache will use the value of the
# ServerName directive.
#
UseCanonicalName Off



Cheers


Richard Hamilton wrote:
> Dear All,
>
> I have Pound set up to reverse proxy from incoming on port 81 (for test
purposes) to a server listening on 8002. For the purposes of this test I am
only concerned with HTTP.
>
> Using IE when I enter http://www.sitename.com:81, Pound does a great job of
passing the request to the backend that listens on port 8002, and the URL shown
in the address bar remains as entered (port 81). However, when I click on links
on the returned page (which are all relative links such as /home/images), the
address bar changes to reflect the port on which the server is listening (port
8002) - http://www.sitename.com:8002/home/contacts . In other words the browser
is now making the request direct to the server on port 8002 rather than through
Pound on port 81.
>
> Puzzlingly, Mozilla does not do this. Mozilla continues to request the
relative urls using port 81, so clearly there is something that IE chooses to
do in the presence or absence of certain information that Mozilla does not do
(I am assuming that Pound does not pass the backend server port information to
the browser deliberately since that would seem to run counter to its intended
function).
>
> In this post
(http://www.apsis.ch/pound/pound_list/archive/2004/2004-02/1075941729000) I see
that Gustav Neumann seems to have addressed this (or a closely related) issue
with his patches to version 1.4 of Pound. He seems to have added a parameter -
[LocationUrlRewrite 1] along with the following explanation:
>
> "Many web-apps (in particular OpenACS) like to redirect http requests to
different urls on the same server..........When the backend (say host:8000)
makes a redirect to itself, the redirect should really point to the proxy
server."
>
> OpenACS sets up many Aolserver request filters which trigger redirects based
upon a set of url structure assumptions and rules, however I don't know for
certain if thi is the issue. Could it be caused by Explorer's interpretation of
the current path from which to seek a relative url? Of one thing I can be
certain - the urls on the site are relative not absolute. I know this because
the reverse proxy works fine both when using Mozilla as the client, and also
when using another reverse proxy solution as an alternative to Pound.
>
> I note that in the current (non beta) version of Pound the LocationUrlRewrite
parameter is not an option and I wondered if this means that I must track down
Gustav's patches and use v1.4, or whether there is something else that I can do
to prevent this happening.
>
> If anyone has any ideas as to why when a request for a relative url is
received from Internet Explorer by Pound, the request is redirected by IE to
port 8002 instead of using the port 81 connection already established, I would
be most grateful to hear about them.
>
> Regards
> Richard
>
>   


Re: [Pound Mailing List] URL Rewriting Issues with Pound Version 2 and OpenACS
"Richard Hamilton" <ricky.hamilton(at)btopenworld.com>
2006-06-15 14:22:34 [ SNIP ]
Thanks for the reply. I use Aolserver rather than Apache, but I can see that 
the principle is the same. I have checked the 'server' directive in the 
Aolserver config file and it is correctly in place. Also it would have to be 
correct for the other reverse proxy solution that I use to work.

Regards
Richard


----- Original Message ----- 
From: "Janno Sannik" <janno(at)foor.ee>
To: <pound(at)apsis.ch>
Sent: Thursday, June 15, 2006 10:59 AM
Subject: Re: [Pound Mailing List] URL Rewriting Issues with Pound Version 2 
and OpenACS


> Have you tried playing with apache conf
> printout from apache conf:
>
> # ServerName gives the name and port that the server uses to identify 
> itself.
> # This can often be determined automatically, but we recommend you specify
> # it explicitly to prevent problems during startup.
> #
> # If this is not set to valid DNS name for your host, server-generated
> # redirections will not work.  See also the UseCanonicalName directive.
> #
> # If your host doesn't have a registered DNS name, enter its IP address 
> here.
> # You will have to access it by its address anyway, and this will make
> # redirections work in a sensible way.
> #
> #ServerName www.example.com:80
>
> #
> # UseCanonicalName: Determines how Apache constructs self-referencing
> # URLs and the SERVER_NAME and SERVER_PORT variables.
> # When set "Off", Apache will use the Hostname and Port supplied
> # by the client.  When set "On", Apache will use the value of the
> # ServerName directive.
> #
> UseCanonicalName Off
>
>
>
> Cheers
>
>
> Richard Hamilton wrote:
>> Dear All,
>>
>> I have Pound set up to reverse proxy from incoming on port 81 (for test 
>> purposes) to a server listening on 8002. For the purposes of this test I 
>> am only concerned with HTTP.
>>
>> Using IE when I enter http://www.sitename.com:81, Pound does a great job 
>> of passing the request to the backend that listens on port 8002, and the 
>> URL shown in the address bar remains as entered (port 81). However, when 
>> I click on links on the returned page (which are all relative links such 
>> as /home/images), the address bar changes to reflect the port on which 
>> the server is listening (port 8002) - 
>> http://www.sitename.com:8002/home/contacts . In other words the browser 
>> is now making the request direct to the server on port 8002 rather than 
>> through Pound on port 81.
>>
>> Puzzlingly, Mozilla does not do this. Mozilla continues to request the 
>> relative urls using port 81, so clearly there is something that IE 
>> chooses to do in the presence or absence of certain information that 
>> Mozilla does not do (I am assuming that Pound does not pass the backend 
>> server port information to the browser deliberately since that would seem 
>> to run counter to its intended function).
>>
>> In this post 
>> (http://www.apsis.ch/pound/pound_list/archive/2004/2004-02/1075941729000) 
>> I see that Gustav Neumann seems to have addressed this (or a closely 
>> related) issue with his patches to version 1.4 of Pound. He seems to have 
>> added a parameter - [LocationUrlRewrite 1] along with the following 
>> explanation:
>>
>> "Many web-apps (in particular OpenACS) like to redirect http requests to 
>> different urls on the same server..........When the backend (say 
>> host:8000) makes a redirect to itself, the redirect should really point 
>> to the proxy server."
>>
>> OpenACS sets up many Aolserver request filters which trigger redirects 
>> based upon a set of url structure assumptions and rules, however I don't 
>> know for certain if thi is the issue. Could it be caused by Explorer's 
>> interpretation of the current path from which to seek a relative url? Of 
>> one thing I can be certain - the urls on the site are relative not 
>> absolute. I know this because the reverse proxy works fine both when 
>> using Mozilla as the client, and also when using another reverse proxy 
>> solution as an alternative to Pound.
>>
>> I note that in the current (non beta) version of Pound the 
>> LocationUrlRewrite parameter is not an option and I wondered if this 
>> means that I must track down Gustav's patches and use v1.4, or whether 
>> there is something else that I can do to prevent this happening.
>>
>> If anyone has any ideas as to why when a request for a relative url is 
>> received from Internet Explorer by Pound, the request is redirected by IE 
>> to port 8002 instead of using the port 81 connection already established, 
>> I would be most grateful to hear about them.
>>
>> Regards
>> Richard
>>
>>
>
>
> -- 
> To unsubscribe send an email with subject 'unsubscribe' to pound(at)apsis.ch.
> Please contact roseg(at)apsis.ch for questions.
>
http://www.apsis.ch/pound/pound_list/archive/2006/2006-06/1150319524000/1150365567000
> 



Re: [Pound Mailing List] URL Rewriting Issues with Pound Version 2 and OpenACS
"Richard Hamilton" <ricky.hamilton(at)btopenworld.com>
2006-06-15 14:43:31 [ SNIP ]
Also, the aolserver config file specifies the items seperately. This excerpt 
is written in tcl, the values on the left are tcl variables and the $ prefix 
specifies variable substitution.

So in this case the hostname returned will be www.server1.com which should 
redirect the request to port 80 (on which my other reverse proxy is 
listening). However when using Internet Explorer it doesn't, it redirects to 
port 8002. That is the puzzle - particularly when Mozilla behaves correctly.


#########################
#########################
#      General Configuration      #
#########################
#########################

set server              "server1" - this is the name of the application 
server instance (for identifying logfile paramteres, and naming log files 
etc.)
set servername          "openacs"

ns_log notice "${server}.tcl:  Starting to read config file..."

set httpport            8002
set httpsport           8445

set hostname            www.${server}.com
set address             10.11.12.13

set homedir             [file dirname [ns_info config]]
set bindir              [file dirname [ns_info nsd]]

set pageroot            /web/${server}/www
set directoryfile       index.tcl,index.adp,index.html,index.htm



Fw: [Pound Mailing List] URL Rewriting Issues with Pound Version 2 and OpenACS
"Richard Hamilton" <ricky.hamilton(at)btopenworld.com>
2006-06-15 15:20:12 [ SNIP ]
I have re-checked the configuration reference and found a parameter that 
might do the trick! Thanks for the pointer. I'll report back.

The parameter is shown below in its appropriate section. For general 
information, if you have nsvhr set up (Virtual Host Redirection through UNIX 
sockets using ad33.13) the addition of ns_param location to the config file 
here in the nssock section prevents your server starting up. What this means 
is that you cannot do what I wanted to do which is test Pound on a different 
port without bringing your services down.

#
# Socket driver module (HTTP)  -- nssock
#
ns_section "ns/server/${servername}/module/nssock"
ns_param   port            $httpport
ns_param   hostname        $host
ns_param   address         $address
ns_param   location        "url"     ;# URL for auto-redirects (trailing 
slash)


Regards
Richard

----- Original Message ----- 
From: "Richard Hamilton" <ricky.hamilton(at)btopenworld.com>
To: <pound(at)apsis.ch>
Sent: Thursday, June 15, 2006 1:22 PM
Subject: Re: [Pound Mailing List] URL Rewriting Issues with Pound Version 2 
and OpenACS


> Thanks for the reply. I use Aolserver rather than Apache, but I can see 
> that the principle is the same. I have checked the 'server' directive in 
> the Aolserver config file and it is correctly in place. Also it would have 
> to be correct for the other reverse proxy solution that I use to work.
>
> Regards
> Richard
>
>
> ----- Original Message ----- 
> From: "Janno Sannik" <janno(at)foor.ee>
> To: <pound(at)apsis.ch>
> Sent: Thursday, June 15, 2006 10:59 AM
> Subject: Re: [Pound Mailing List] URL Rewriting Issues with Pound Version 
> 2 and OpenACS
>
>
>> Have you tried playing with apache conf
>> printout from apache conf:
>>
>> # ServerName gives the name and port that the server uses to identify 
>> itself.
>> # This can often be determined automatically, but we recommend you 
>> specify
>> # it explicitly to prevent problems during startup.
>> #
>> # If this is not set to valid DNS name for your host, server-generated
>> # redirections will not work.  See also the UseCanonicalName directive.
>> #
>> # If your host doesn't have a registered DNS name, enter its IP address 
>> here.
>> # You will have to access it by its address anyway, and this will make
>> # redirections work in a sensible way.
>> #
>> #ServerName www.example.com:80
>>
>> #
>> # UseCanonicalName: Determines how Apache constructs self-referencing
>> # URLs and the SERVER_NAME and SERVER_PORT variables.
>> # When set "Off", Apache will use the Hostname and Port supplied
>> # by the client.  When set "On", Apache will use the value of the
>> # ServerName directive.
>> #
>> UseCanonicalName Off
>>
>>
>>
>> Cheers
>>
>>
>> Richard Hamilton wrote:
>>> Dear All,
>>>
>>> I have Pound set up to reverse proxy from incoming on port 81 (for test 
>>> purposes) to a server listening on 8002. For the purposes of this test I 
>>> am only concerned with HTTP.
>>>
>>> Using IE when I enter http://www.sitename.com:81, Pound does a great job 
>>> of passing the request to the backend that listens on port 8002, and the 
>>> URL shown in the address bar remains as entered (port 81). However, when 
>>> I click on links on the returned page (which are all relative links such 
>>> as /home/images), the address bar changes to reflect the port on which 
>>> the server is listening (port 8002) - 
>>> http://www.sitename.com:8002/home/contacts . In other words the browser 
>>> is now making the request direct to the server on port 8002 rather than 
>>> through Pound on port 81.
>>>
>>> Puzzlingly, Mozilla does not do this. Mozilla continues to request the 
>>> relative urls using port 81, so clearly there is something that IE 
>>> chooses to do in the presence or absence of certain information that 
>>> Mozilla does not do (I am assuming that Pound does not pass the backend 
>>> server port information to the browser deliberately since that would 
>>> seem to run counter to its intended function).
>>>
>>> In this post 
>>> (http://www.apsis.ch/pound/pound_list/archive/2004/2004-02/1075941729000) 
>>> I see that Gustav Neumann seems to have addressed this (or a closely 
>>> related) issue with his patches to version 1.4 of Pound. He seems to 
>>> have added a parameter - [LocationUrlRewrite 1] along with the following 
>>> explanation:
>>>
>>> "Many web-apps (in particular OpenACS) like to redirect http requests to 
>>> different urls on the same server..........When the backend (say 
>>> host:8000) makes a redirect to itself, the redirect should really point 
>>> to the proxy server."
>>>
>>> OpenACS sets up many Aolserver request filters which trigger redirects 
>>> based upon a set of url structure assumptions and rules, however I don't 
>>> know for certain if thi is the issue. Could it be caused by Explorer's 
>>> interpretation of the current path from which to seek a relative url? Of 
>>> one thing I can be certain - the urls on the site are relative not 
>>> absolute. I know this because the reverse proxy works fine both when 
>>> using Mozilla as the client, and also when using another reverse proxy 
>>> solution as an alternative to Pound.
>>>
>>> I note that in the current (non beta) version of Pound the 
>>> LocationUrlRewrite parameter is not an option and I wondered if this 
>>> means that I must track down Gustav's patches and use v1.4, or whether 
>>> there is something else that I can do to prevent this happening.
>>>
>>> If anyone has any ideas as to why when a request for a relative url is 
>>> received from Internet Explorer by Pound, the request is redirected by 
>>> IE to port 8002 instead of using the port 81 connection already 
>>> established, I would be most grateful to hear about them.
>>>
>>> Regards
>>> Richard
>>>
>>>
>>
>>
>> -- 
>> To unsubscribe send an email with subject 'unsubscribe' to 
>> pound(at)apsis.ch.
>> Please contact roseg(at)apsis.ch for questions.
>>
http://www.apsis.ch/pound/pound_list/archive/2006/2006-06/1150319524000/1150365567000
>>
>
>
>
> -- 
> To unsubscribe send an email with subject 'unsubscribe' to pound(at)apsis.ch.
> Please contact roseg(at)apsis.ch for questions.
>
http://www.apsis.ch/pound/pound_list/archive/2006/2006-06/1150319524000/1150374154000
> 



Fw: [Pound Mailing List] URL Rewriting Issues with Pound Version 2 and OpenACS
"Richard Hamilton" <ricky.hamilton(at)btopenworld.com>
2006-06-15 16:17:21 [ SNIP ]
More information.

I have put that parameter in place and now the redirection works just fine 
in OpenACS under http. However, this now throws up another problem which is 
that the redirection to the https listener, which previously worked just 
fine, is now broken. This is because the url is being re-written to the http 
location after the scripts trigger the re-direct, where before it 
re-directed just fine to https://www.server1.com:8450

I will hunt through for some more parameters but at present the redirect to 
https now fails a it is re-written to http.

Regards
Richard 



Re: [Pound Mailing List] URL Rewriting Issues with Pound Version 2 and OpenACS
"Richard Hamilton" <ricky.hamilton(at)btopenworld.com>
2006-06-15 18:58:03 [ SNIP ]
OK, now have established that the https redirect is an issue with the test set
up that I have, so on the face of it the addition of the ns_param location
parameter seems to solve the problem.

Thanks for the help and guidance.

I have one other question about running Pound.

Initially I though that I would need to run Pound from inittab in order to make
sure that if for some reason it died, it would be re-started. However, when I
did this it kept re-spawning. I asked the question and Robert very kindly
replied that I need to configure Pound at compile time without supervisor
process and not to put itself into the background.

So although now I know HOW to run Pound from inittab (or daemontools), my
question becomes 'should I'?

Am I correct in thinking that Pound:

1) Puts itself into the background as the specified, non-root user

and

2) Maintains a monitoring process whose job it is to monitor Pound and to
re-start it if it dies for some reason.

If so, am I correct in thinking that I need only start Pound from any suitable
startup script since it self monitors and keeps itself alive without recourse
to inittab or daemontools?

Many Thanks
Richard


Attachments:  
text.html text/html 2527 Bytes

Re: [Pound Mailing List] URL Rewriting Issues with Pound Version 2 and OpenACS
"Richard Hamilton" <ricky.hamilton(at)btopenworld.com>
2006-06-17 13:58:23 [ SNIP ]
Oh dear, no I was wrong - too hasty. The https redirect issue in not a web 
server issue - it works fine when using Mozilla and/or when using my other 
Aolserver based reverse proxy solution. So I am back asking questions again! 
:-|

The situation in summary is:

I have set up Pound to listen on port 80 and set up a domain (an existing, 
fully tested production site) on port 8000 (www.server1.com). I have set up 
a Pound config file that is shown below.

If I connect directly to http://www.server1.com:8000 using Internet 
Explorer, everything works fine including https redirects to port 8443. Any 
subsequent browsing remains on https, port 8443.

If I do the same with Mozilla, everything works fine too.

Now I try using Pound:

When I use Mozilla to view the website through Pound 
(http://ww.server1.com), everything works just fine. When I click on links 
to relative urls on the website (and I have checked the source html - they 
are relative links), all the links work fine including those that redirect 
to the https listener which I have on a different port. When someone 
authenticates on my site I redirect them to https on another port such as 
8443. (I do not need or want to set up pound to handle the https traffic 
since one redirected the user can continue to browse using the secure port).

HOWEVER!

If I use Internet Explorer to view the website through Pound, when I click 
on a relative link I get mangled urls in the Explorer address bar. They look 
like this:

http://www.server1.com/www.server1.com/home/document

Now as I mentioned in a previous post, I can prevent this (for http only) by 
adding an Aolserver configuration parameter to add a Location header to the 
http requests. But, my problem then is that because of the added location 
header which points to the http connection, any relative links selected by a 
browser communicating through the https listener on port 443 will cause the 
browser to switch back to the non secure http connection - which I don't 
want to happen.

Now I have read somewhere that Internet Explorer does funny things with 
redirects if the connection is on a non-standard port. Perhaps this is a 
related problem, however it is manifest only with the combination of Pound 
and Internet Explorer. So even if the bug is in fact in IE, I would very 
much like to find a workaround or a fix since IE represents about 98% of the 
client connections to my website! :-(

Does anyone have any idea how or why this could be happening and can anyone 
recommend a tool that I can use to examine the traffic between the browser 
and Pound, and between Pound and the web server to establish what Pound does 
to the request on its way through that is triggering the buggy behaviour in 
Internet Explorer?

Many Thanks

Regards
Richard

______________________________________________________________________________________

POUND CONFIG FILE FOR INFO:

##################
# Global Options #
##################

User            "pound"
Group           "pound"
#RootJail       /chroot/pound
#Daemon         1

## Logging: (goes to syslog by default)
##      0       no logging
##      1       normal
##      2       extended
##      3       Apache-style (common log format)
#LogFacility    daemon
LogLevel        1

## check backend every X secs:
Alive           60

## use hardware-acceleration card supported by openssl(1):
#SSLEngine      <hw>


##################
# HTTP Listening #
##################

ListenHTTP
    Address     1.2.3.4
    Port        80
    ## allow PUT and DELETE also (by default only GET, POST and HEAD)?:
    #xHTTP       0
    WebDAV       1
    Client      10
    #CheckURL    "<pattern to match>"
    #Err414      "<filename>"
    #Err500      "<filename>"
    #Err501      "<filename>"
    #Err503      "<filename>"
    #MaxRequest  nn
    #HeadRemove  "<header pattern>"
    #Change30x   0|1
    #Service     <Non-Global if nested inside ListenHTTP>
End


#####################
# Services (Global) #
#####################


# tradea configuration
######################

Service
    #URL          ".*"
    HeadRequire  "Host:.*www.server1.com.*"
    #HeadDeny     "<pattern>"
    Backend
        Address      1.2.3.4
        Port         8000
        #Priority     <1 - 9>
        #Timeout      <default - 15 seconds>
        #HAport       <For high availability checks>
    End
    #Redirect    "<url>"
    #Session     "<configure for session tracking>"
        #Type        IP|BASIC|PARM|COOKIE|HEADER
        #TTL         <seconds>
        #ID          <Parameter name for 'Type' PARM>
End


----- Original Message ----- 
From: "Richard Hamilton" <ricky.hamilton(at)btopenworld.com>
To: <pound(at)apsis.ch>
Sent: Thursday, June 15, 2006 5:58 PM
Subject: Re: [Pound Mailing List] URL Rewriting Issues with Pound Version 2 
and OpenACS


> OK, now have established that the https redirect is an issue with the test 
> set up that I have, so on the face of it the addition of the ns_param 
> location parameter seems to solve the problem.
>
> Thanks for the help and guidance.
>
> I have one other question about running Pound.
>
> Initially I though that I would need to run Pound from inittab in order to 
> make sure that if for some reason it died, it would be re-started. 
> However, when I did this it kept re-spawning. I asked the question and 
> Robert very kindly replied that I need to configure Pound at compile time 
> without supervisor process and not to put itself into the background.
>
> So although now I know HOW to run Pound from inittab (or daemontools), my 
> question becomes 'should I'?
>
> Am I correct in thinking that Pound:
>
> 1) Puts itself into the background as the specified, non-root user
>
> and
>
> 2) Maintains a monitoring process whose job it is to monitor Pound and to 
> re-start it if it dies for some reason.
>
> If so, am I correct in thinking that I need only start Pound from any 
> suitable startup script since it self monitors and keeps itself alive 
> without recourse to inittab or daemontools?
>
> Many Thanks
> Richard
>
>
>
> -- 
> To unsubscribe send an email with subject 'unsubscribe' to pound(at)apsis.ch.
> Please contact roseg(at)apsis.ch for questions.
>
http://www.apsis.ch/pound/pound_list/archive/2006/2006-06/1150319524000/1150390683000
> 



Re: [Pound Mailing List] URL Rewriting Issues with Pound Version 2 and OpenACS
"Richard Hamilton" <ricky.hamilton(at)btopenworld.com>
2006-06-18 14:54:22 [ SNIP ]
I have also found this information which relates to setting up Apache as a 
reverse proxy.

"For example, when using the proxypass directive and accessing 
www.mcslp.com/marketing/index.html, the client browser will still be able to 
identify the true source of the data as marketing.mcslp.com/index.html just 
by looking at the HTTP headers returned.
The one downside is that this can cause problems with relative links in 
pages that would ultimately point to the true server, not the proxy server 
we're trying to hide behind. Solving this problem requires an additional 
directive, ProxyPassReverse. This forces the proxy module to rewrite the 
HTTP header fields Location, Content-Location, and URI with the address of 
the proxy server, not the true server."

So I suppose my question boils down to this - does Pound have the facility 
to do what ProxyPassReverse does for Apache?

I believe that Gustav Neumann's patches to version 1.4 did just this but the 
config parameter LocationUrlRewrite seems to be absent from recent versions.

I note in this thread...

http://www.apsis.ch/pound/pound_list/archive/2004/2004-02/1075941729000#1075941729000

a comment from Bart that version 1.4 of Pound was the only version to be 
compatible with OpenACS at the time he posted. He also asked if there was 
any possibility of the patches being incorporated to permit Pound to be used 
with OpenACS going forward. Was this in fact incorporated?

As there are published security issues with versions of Pound prior to 
version 1.6, I dare not install version 1.4 with patches.

Would the author be willing to look at resolving this in future versions?

Regards

Richard





----- Original Message ----- 
From: "Richard Hamilton" <ricky.hamilton(at)btopenworld.com>
To: <pound(at)apsis.ch>
Sent: Saturday, June 17, 2006 12:58 PM
Subject: Re: [Pound Mailing List] URL Rewriting Issues with Pound Version 2 
and OpenACS


> Oh dear, no I was wrong - too hasty. The https redirect issue in not a web 
> server issue - it works fine when using Mozilla and/or when using my other 
> Aolserver based reverse proxy solution. So I am back asking questions 
> again! :-|
>
> The situation in summary is:
>
> I have set up Pound to listen on port 80 and set up a domain (an existing, 
> fully tested production site) on port 8000 (www.server1.com). I have set 
> up a Pound config file that is shown below.
>
> If I connect directly to http://www.server1.com:8000 using Internet 
> Explorer, everything works fine including https redirects to port 8443. 
> Any subsequent browsing remains on https, port 8443.
>
> If I do the same with Mozilla, everything works fine too.
>
> Now I try using Pound:
>
> When I use Mozilla to view the website through Pound 
> (http://ww.server1.com), everything works just fine. When I click on links 
> to relative urls on the website (and I have checked the source html - they 
> are relative links), all the links work fine including those that redirect 
> to the https listener which I have on a different port. When someone 
> authenticates on my site I redirect them to https on another port such as 
> 8443. (I do not need or want to set up pound to handle the https traffic 
> since one redirected the user can continue to browse using the secure 
> port).
>
> HOWEVER!
>
> If I use Internet Explorer to view the website through Pound, when I click 
> on a relative link I get mangled urls in the Explorer address bar. They 
> look like this:
>
> http://www.server1.com/www.server1.com/home/document
>
> Now as I mentioned in a previous post, I can prevent this (for http only) 
> by adding an Aolserver configuration parameter to add a Location header to 
> the http requests. But, my problem then is that because of the added 
> location header which points to the http connection, any relative links 
> selected by a browser communicating through the https listener on port 443 
> will cause the browser to switch back to the non secure http connection - 
> which I don't want to happen.
>
> Now I have read somewhere that Internet Explorer does funny things with 
> redirects if the connection is on a non-standard port. Perhaps this is a 
> related problem, however it is manifest only with the combination of Pound 
> and Internet Explorer. So even if the bug is in fact in IE, I would very 
> much like to find a workaround or a fix since IE represents about 98% of 
> the client connections to my website! :-(
>
> Does anyone have any idea how or why this could be happening and can 
> anyone recommend a tool that I can use to examine the traffic between the 
> browser and Pound, and between Pound and the web server to establish what 
> Pound does to the request on its way through that is triggering the buggy 
> behaviour in Internet Explorer?
>
> Many Thanks
>
> Regards
> Richard
>
>
______________________________________________________________________________________
>
> POUND CONFIG FILE FOR INFO:
>
> ##################
> # Global Options #
> ##################
>
> User            "pound"
> Group           "pound"
> #RootJail       /chroot/pound
> #Daemon         1
>
> ## Logging: (goes to syslog by default)
> ##      0       no logging
> ##      1       normal
> ##      2       extended
> ##      3       Apache-style (common log format)
> #LogFacility    daemon
> LogLevel        1
>
> ## check backend every X secs:
> Alive           60
>
> ## use hardware-acceleration card supported by openssl(1):
> #SSLEngine      <hw>
>
>
> ##################
> # HTTP Listening #
> ##################
>
> ListenHTTP
>    Address     1.2.3.4
>    Port        80
>    ## allow PUT and DELETE also (by default only GET, POST and HEAD)?:
>    #xHTTP       0
>    WebDAV       1
>    Client      10
>    #CheckURL    "<pattern to match>"
>    #Err414      "<filename>"
>    #Err500      "<filename>"
>    #Err501      "<filename>"
>    #Err503      "<filename>"
>    #MaxRequest  nn
>    #HeadRemove  "<header pattern>"
>    #Change30x   0|1
>    #Service     <Non-Global if nested inside ListenHTTP>
> End
>
>
> #####################
> # Services (Global) #
> #####################
>
>
> # tradea configuration
> ######################
>
> Service
>    #URL          ".*"
>    HeadRequire  "Host:.*www.server1.com.*"
>    #HeadDeny     "<pattern>"
>    Backend
>        Address      1.2.3.4
>        Port         8000
>        #Priority     <1 - 9>
>        #Timeout      <default - 15 seconds>
>        #HAport       <For high availability checks>
>    End
>    #Redirect    "<url>"
>    #Session     "<configure for session tracking>"
>        #Type        IP|BASIC|PARM|COOKIE|HEADER
>        #TTL         <seconds>
>        #ID          <Parameter name for 'Type' PARM>
> End
>
>
> ----- Original Message ----- 
> From: "Richard Hamilton" <ricky.hamilton(at)btopenworld.com>
> To: <pound(at)apsis.ch>
> Sent: Thursday, June 15, 2006 5:58 PM
> Subject: Re: [Pound Mailing List] URL Rewriting Issues with Pound Version 
> 2 and OpenACS
>
>
>> OK, now have established that the https redirect is an issue with the 
>> test set up that I have, so on the face of it the addition of the 
>> ns_param location parameter seems to solve the problem.
>>
>> Thanks for the help and guidance.
>>
>> I have one other question about running Pound.
>>
>> Initially I though that I would need to run Pound from inittab in order 
>> to make sure that if for some reason it died, it would be re-started. 
>> However, when I did this it kept re-spawning. I asked the question and 
>> Robert very kindly replied that I need to configure Pound at compile time 
>> without supervisor process and not to put itself into the background.
>>
>> So although now I know HOW to run Pound from inittab (or daemontools), my 
>> question becomes 'should I'?
>>
>> Am I correct in thinking that Pound:
>>
>> 1) Puts itself into the background as the specified, non-root user
>>
>> and
>>
>> 2) Maintains a monitoring process whose job it is to monitor Pound and to 
>> re-start it if it dies for some reason.
>>
>> If so, am I correct in thinking that I need only start Pound from any 
>> suitable startup script since it self monitors and keeps itself alive 
>> without recourse to inittab or daemontools?
>>
>> Many Thanks
>> Richard
>>
>>
>>
>> -- 
>> To unsubscribe send an email with subject 'unsubscribe' to 
>> pound(at)apsis.ch.
>> Please contact roseg(at)apsis.ch for questions.
>>
http://www.apsis.ch/pound/pound_list/archive/2006/2006-06/1150319524000/1150390683000
>>
>
>
>
> -- 
> To unsubscribe send an email with subject 'unsubscribe' to pound(at)apsis.ch.
> Please contact roseg(at)apsis.ch for questions.
>
http://www.apsis.ch/pound/pound_list/archive/2006/2006-06/1150319524000/1150545503000
> 


Re: [Pound Mailing List] URL Rewriting Issues with Pound Version 2 and OpenACS
Robert Segall <roseg(at)apsis.ch>
2006-06-19 19:06:22 [ SNIP ]
Please try the just-released 2.0.8. Make sure you set the
RewriteLocation parameter.

I hope this solves the problems you have seen. Please let us know.
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-44-920 4904


Re: [Pound Mailing List] URL Rewriting Issues with Pound Version 2 and OpenACS
"Richard Hamilton" <ricky.hamilton(at)btopenworld.com>
2006-06-20 00:28:12 [ SNIP ]
Oh fantastic - thank you Robert very much.

R.

----- Original Message ----- 
From: "Robert Segall" <roseg(at)apsis.ch>
To: <pound(at)apsis.ch>
Sent: Monday, June 19, 2006 6:06 PM
Subject: Re: [Pound Mailing List] URL Rewriting Issues with Pound Version 2 
and OpenACS


> Please try the just-released 2.0.8. Make sure you set the
> RewriteLocation parameter.
>
> I hope this solves the problems you have seen. Please let us know.
> -- 
> Robert Segall
> Apsis GmbH
> Postfach, Uetikon am See, CH-8707
> Tel: +41-44-920 4904
>
>
> -- 
> To unsubscribe send an email with subject 'unsubscribe' to pound(at)apsis.ch.
> Please contact roseg(at)apsis.ch for questions.
>
http://www.apsis.ch/pound/pound_list/archive/2006/2006-06/1150319524000/1150736782000
> 



Re: [Pound Mailing List] URL Rewriting Issues with Pound Version 2 and OpenACS
"Richard Hamilton" <ricky.hamilton(at)btopenworld.com>
2006-06-21 22:24:16 [ SNIP ]
Robert,

I also see the 'cannot find MKDIST.in' error on RedHat 8.0

Regards
Richard

----- Original Message ----- 
From: "Robert Segall" <roseg(at)apsis.ch>
To: <pound(at)apsis.ch>
Sent: Monday, June 19, 2006 6:06 PM
Subject: Re: [Pound Mailing List] URL Rewriting Issues with Pound Version 2 
and OpenACS


> Please try the just-released 2.0.8. Make sure you set the
> RewriteLocation parameter.
>
> I hope this solves the problems you have seen. Please let us know.
> -- 
> Robert Segall
> Apsis GmbH
> Postfach, Uetikon am See, CH-8707
> Tel: +41-44-920 4904
>
>
> -- 
> To unsubscribe send an email with subject 'unsubscribe' to pound(at)apsis.ch.
> Please contact roseg(at)apsis.ch for questions.
>
http://www.apsis.ch/pound/pound_list/archive/2006/2006-06/1150319524000/1150736782000
> 



RE: [Pound Mailing List] URL Rewriting Issues with Pound Version 2 and OpenACS
"Sarah Brennan" <sarah.brennan(at)navman.com>
2006-06-21 22:55:09 [ SNIP ]
Same here on SUSE 10.

Sarah

-----Original Message-----
From: Richard Hamilton [mailto:ricky.hamilton(at)btopenworld.com] 
Sent: Thursday, 22 June 2006 8:24 a.m.
To: pound(at)apsis.ch
Subject: Re: [Pound Mailing List] URL Rewriting Issues with Pound
Version 2 and OpenACS

Robert,

I also see the 'cannot find MKDIST.in' error on RedHat 8.0

Regards
Richard

----- Original Message ----- 
From: "Robert Segall" <roseg(at)apsis.ch>
To: <pound(at)apsis.ch>
Sent: Monday, June 19, 2006 6:06 PM
Subject: Re: [Pound Mailing List] URL Rewriting Issues with Pound
Version 2 
and OpenACS


> Please try the just-released 2.0.8. Make sure you set the
> RewriteLocation parameter.
>
> I hope this solves the problems you have seen. Please let us know.
> -- 
> Robert Segall
> Apsis GmbH
> Postfach, Uetikon am See, CH-8707
> Tel: +41-44-920 4904
>
>
> -- 
> To unsubscribe send an email with subject 'unsubscribe' to
pound(at)apsis.ch.
> Please contact roseg(at)apsis.ch for questions.
>
http://www.apsis.ch/pound/pound_list/archive/2006/2006-06/1150319524000/
1150736782000
> 



-- 
To unsubscribe send an email with subject 'unsubscribe' to
pound(at)apsis.ch.
Please contact roseg(at)apsis.ch for questions.
http://www.apsis.ch/pound/pound_list/archive/2006/2006-06/1150319524000/
1150921456000

RE: [Pound Mailing List] URL Rewriting Issues with Pound Version 2 and OpenACS
"Sarah Brennan" <sarah.brennan(at)navman.com>
2006-06-21 23:10:50 [ SNIP ]
Same here on SUSE 10.

Sarah

-----Original Message-----
From: Richard Hamilton [mailto:ricky.hamilton(at)btopenworld.com] 
Sent: Thursday, 22 June 2006 8:24 a.m.
To: pound(at)apsis.ch
Subject: Re: [Pound Mailing List] URL Rewriting Issues with Pound
Version 2 and OpenACS

Robert,

I also see the 'cannot find MKDIST.in' error on RedHat 8.0

Regards
Richard

----- Original Message ----- 
From: "Robert Segall" <roseg(at)apsis.ch>
To: <pound(at)apsis.ch>
Sent: Monday, June 19, 2006 6:06 PM
Subject: Re: [Pound Mailing List] URL Rewriting Issues with Pound
Version 2 
and OpenACS


> Please try the just-released 2.0.8. Make sure you set the
> RewriteLocation parameter.
>
> I hope this solves the problems you have seen. Please let us know.
> -- 
> Robert Segall
> Apsis GmbH
> Postfach, Uetikon am See, CH-8707
> Tel: +41-44-920 4904
>
>
> -- 
> To unsubscribe send an email with subject 'unsubscribe' to
pound(at)apsis.ch.
> Please contact roseg(at)apsis.ch for questions.
>
http://www.apsis.ch/pound/pound_list/archive/2006/2006-06/1150319524000/
1150736782000
> 



-- 
To unsubscribe send an email with subject 'unsubscribe' to
pound(at)apsis.ch.
Please contact roseg(at)apsis.ch for questions.
http://www.apsis.ch/pound/pound_list/archive/2006/2006-06/1150319524000/
1150921456000

Re: [Pound Mailing List] URL Rewriting Issues with Pound Version 2 and OpenACS
"Richard Hamilton" <ricky.hamilton(at)btopenworld.com>
2006-06-21 23:40:38 [ SNIP ]
I have now installed 2.0.8 and tested with OpenACS backends. The standard 
proxy behaviour under http is perfect now - thank you! :-)

I have one remaining issue which someone may be able to help me with......

When selecting links to protected pages in OpenACS, the server issues a 
redirect to a secure location under https. Using IE to select relative links 
with Pound 2.0.8 now leads to a Pound error saying 'please use https'. How 
can I now configure pound to honour the redirect to https on a different 
port? (I wonder if there needs to be a parameter to set the behaviour of the 
RewriteLocation function such that it optionally only rewrites http 
locations?)

The reason that this is needed in OpenACS is that each server has both an 
http listener and an https listener and each site may have its own security 
certificate. I therefore redirect users to the secure port for access to non 
public areas. A relative link to a section of the site that is protected 
triggers a return/redirect to for example:

https://www.server1.com:8443/relative/url

Basically I do not want to use Pound for handling https traffic - only http.

Any ideas gratefully accepted.

Richard


----- Original Message ----- 
From: "Sarah Brennan" <sarah.brennan(at)navman.com>
To: <pound(at)apsis.ch>
Sent: Wednesday, June 21, 2006 10:10 PM
Subject: RE: [Pound Mailing List] URL Rewriting Issues with Pound Version 2 
and OpenACS


Same here on SUSE 10.

Sarah

-----Original Message-----
From: Richard Hamilton [mailto:ricky.hamilton(at)btopenworld.com]
Sent: Thursday, 22 June 2006 8:24 a.m.
To: pound(at)apsis.ch
Subject: Re: [Pound Mailing List] URL Rewriting Issues with Pound
Version 2 and OpenACS

Robert,

I also see the 'cannot find MKDIST.in' error on RedHat 8.0

Regards
Richard

----- Original Message ----- 
From: "Robert Segall" <roseg(at)apsis.ch>
To: <pound(at)apsis.ch>
Sent: Monday, June 19, 2006 6:06 PM
Subject: Re: [Pound Mailing List] URL Rewriting Issues with Pound
Version 2
and OpenACS


> Please try the just-released 2.0.8. Make sure you set the
> RewriteLocation parameter.
>
> I hope this solves the problems you have seen. Please let us know.
> -- 
> Robert Segall
> Apsis GmbH
> Postfach, Uetikon am See, CH-8707
> Tel: +41-44-920 4904
>
>
> -- 
> To unsubscribe send an email with subject 'unsubscribe' to
pound(at)apsis.ch.
> Please contact roseg(at)apsis.ch for questions.
>
http://www.apsis.ch/pound/pound_list/archive/2006/2006-06/1150319524000/
1150736782000
>



-- 
To unsubscribe send an email with subject 'unsubscribe' to
pound(at)apsis.ch.
Please contact roseg(at)apsis.ch for questions.
http://www.apsis.ch/pound/pound_list/archive/2006/2006-06/1150319524000/
1150921456000

-- 
To unsubscribe send an email with subject 'unsubscribe' to pound(at)apsis.ch.
Please contact roseg(at)apsis.ch for questions.
http://www.apsis.ch/pound/pound_list/archive/2006/2006-06/1150319524000/1150924250000



Re: [Pound Mailing List] URL Rewriting Issues with Pound Version 2 and OpenACS
"Richard Hamilton" <ricky.hamilton(at)btopenworld.com>
2006-06-22 22:08:44 [ SNIP ]
I have been thinking this through a little more today.

If I understand correctly, the new config parameter RewriteLocation tells 
pound to rewrite the host headers provided by proxied backends so that they 
carry the url for the Pound proxy rather than for the backend. This avoids 
inadvertant re-direction of the connection and makes relative links work 
properly so that subsequent page requests are made through the proxy rather 
than to the webserver direct.

At present this parameter results in ALL headers being rewritten 
irrespective of any change in protocol.

Now I have a situation where I actually want to be able to hand a connection 
off to a dedicated port for secure, https connections. As things stand I 
don't think that it is not going to work because since ALL of the headers 
are rewritten when the redirect header passes through Pound on its way back 
to the browser, the host header 'https://www.server.com:8443' is replaced 
with 'http://www.server.com'. This kills the redirect and breaks the web 
service.

In order to increase Pound's flexibility is this respect therefore I would 
like to propose that RewriteLocation be modified to add an additional mode 
of operation:

RewriteLocation   off | all | http-only

This would allow the admin to restrict the activity of the rewrite to only 
headers containing urls beginning with 'http://' and would allow Pound to be 
configured to either:

1) Not rewrite headers at all
 or
2) Rewrite location headers for both http and https locations (in which case 
Pound must be configured to handle the ssl connection using the Pound 
certfile)
or
3) Redirect http traffic only such that any header that represents an 
explicit 30x redirect to an https location does not have its location 
rewritten.

Does anyone have any comments on this suggestion?

Regards
Richard



Re: [Pound Mailing List] URL Rewriting Issues with Pound Version 2 and OpenACS
"Richard Hamilton" <ricky.hamilton(at)btopenworld.com>
2006-06-25 00:01:36 [ SNIP ]
I have now installed Pound 2.0.9 and checked the reverse proxy functionality 
with both Mozilla and Explorer.

Unfortunately, the redirect to https://www.server.com:8443/my/page now fails 
in both browsers and produces a simple html page saying 'Please use HTTPS' 
(is this Pound generated?). I do not have the https listener on Pound set up 
because I want requests for protected resources to be redirected to an https 
connection on a different port on the same backend. It is this redirect that 
is failing.

The url makes a request of a resource that is protected and the server 
issues a redirect, however I think that pound is still rewriting fields in 
the header because the browser never requests the https url which is sent by 
the server during the redirect. Until I can study the http headers that are 
being transferred between Pound, the browser and the backend, I am not able 
to throw much light on things.

Does anyone know of a useful tool that I can use to grab the http headers so 
that I can study and compare with my other reverse proxy solution?

Does anyone have any suggestions as to why this is happening?

Regards
Richard 


Re: [Pound Mailing List] URL Rewriting Issues with Pound Version 2 and OpenACS
"Richard Hamilton" <ricky.hamilton(at)btopenworld.com>
2006-06-25 00:18:08 [ SNIP ]
Further to last message. I have established the origin of the 'Please use 
HTTPS' page - it is indeed a page returned by OpenACS when there is a 
problem redirecting to https.

I have studied the code and it seems that it devises a redirect based upon 
the port number. If the https port number is something other than 8443, the 
server issues a redirect to a url created in the following way:

Url for redirect becomes: "https://${host}:${ssl_port}${url}"

Now the important thing to note here is that the variable ${host} takes its 
value direct from the http host header, ${ssl_port} comes from a config file 
and url is the relative url of the link.

So that means that the only explanation for this is that Pound must be 
rewriting the host header as the redirect passes through.

What should happen is that an incoming request for 
http://www.server.com/private/index should be intercepted (as it is for a 
secure resource), and an http redirect to a url constructed as described 
above. This redirect should therefore carry the url - 
https://www.server.com:8443/private/index

The browser should now of course request that url direct with port 8443.

However, I think that Pound is rewriting this url on its way to the browser 
to restore it to:

http://www.server.com/private/index

and this prevents the redirect from working as expected.

I hope that this information is helpful.

Regards
Richard 


Re: [Pound Mailing List] URL Rewriting Issues with Pound Version 2 and OpenACS
"Richard Hamilton" <ricky.hamilton(at)btopenworld.com>
2006-06-25 00:21:44 [ SNIP ]
Just to record a typo in my last post - I meant port 443 not 8443 as 
follows:

{
I have studied the code and it seems that it devises a redirect based upon
the port number. If the https port number is something other than 443, the
server issues a redirect to a url created in the following way:

Url for redirect becomes: https://${host}:${ssl_port}${url}
}


Re: [Pound Mailing List] URL Rewriting Issues with Pound Version 2 and OpenACS
Ted Dunning <tdunning(at)veoh.com>
2006-06-25 00:36:22 [ SNIP ]
Can you send your config out again for people to look at?

Richard Hamilton wrote:
> Just to record a typo in my last post - I meant port 443 not 8443 as 
> follows:
>
> {
> I have studied the code and it seems that it devises a redirect based 
> upon
> the port number. If the https port number is something other than 443, 
> the
> server issues a redirect to a url created in the following way:
>
> Url for redirect becomes: https://${host}:${ssl_port}${url}
> }
>
>

-- 
Ted Dunning
Chief Scientist
Veoh Networks



Re: [Pound Mailing List] URL Rewriting Issues with Pound Version 2 and OpenACS
"Richard Hamilton" <ricky.hamilton(at)btopenworld.com>
2006-06-25 17:16:37 [ SNIP ]
# POUND CONFIGURATION FILE
# Prepared by Richard Hamilton on 11606
# richard.hamilton(at)datastreammedia.com
#
# Note: This config file lists all non HTTPS directives. For a full
# account of each option type 'man pound' at the shell prompt. HTTPS
# reverse proxy is not needed because each client 
# website has its own Aolserver instance which listens on two ports,
# one insecure and one secure. The OpenACS request processor deals
# with redirecting requests to the secure listener. Once the user
# has been passed to the HTTPS listener all subsequent activity
# uses URLs that connect directly to the HTTPS listener on its own
# port. So the switch to HTTPS is initiated by a redirect from the
# OpenACS request processor in response to a normally proxied HTTP
# request. Not only is reverse proxy of HTTPS impossible, it is also
# not necessary. (James Thornton has published an example of using
# Aolserver4 nsvhr where all virtual servers run in one Aolserver 
# process, such that Pound reverse proxies HTTPS connections to 
# OpenACS subsites. Could be useful but not if seperate control of
# servers or separation data is required.)



##################
# Global Options #
##################

User            "pound"
Group           "pound"
#RootJail       /chroot/pound
#Daemon         1

## Logging: (goes to syslog by default)
##      0       no logging
##      1       normal
##      2       extended
##      3       Apache-style (common log format)
#LogFacility    daemon
LogLevel        1

## check backend every X secs:
Alive           60

## use hardware-acceleration card supported by openssl(1):
#SSLEngine      <hw>


##################
# HTTP Listening #
##################

ListenHTTP
    Address          63.246.8.13
    Port             81
    ## allow PUT and DELETE also (by default only GET, POST and HEAD)?:
    #xHTTP            0
    WebDAV            1
    Client           10
    #CheckURL         "<pattern to match>"
    #Err414           "<filename>"
    #Err500           "<filename>"
    #Err501           "<filename>"
    #Err503           "<filename>"
    #MaxRequest       nn
    #HeadRemove       "<header pattern>"
    RewriteLocation   1
    #Service          <Non-Global if nested inside ListenHTTP>
End


#####################
# Services (Global) #
#####################


# server1 configuration
######################

Service
    #URL          ".*"
    HeadRequire  "Host:.*www.server1.com.*"
    #HeadDeny     "<pattern>"
    Backend
        Address      63.246.8.13
        Port         8001
        #Priority     <1 - 9>
        #Timeout      <default - 15 seconds>
        #HAport       <For high availability checks>
    End
    #Redirect    "<url>"
    #Session     "<configure for session tracking>"
        #Type        IP|BASIC|PARM|COOKIE|HEADER
        #TTL         <seconds>
        #ID          <Parameter name for 'Type' PARM>
End


# server2 configuration
##########################

Service
    URL          ".*"
    HeadRequire  "Host:.*www.server2.com.*"
    #HeadDeny     "<pattern>"
    Backend
        Address      63.246.8.13
        Port         8002
        #Priority     <1 - 9>
        #Timeout      <default - 15 seconds>
        #HAport       <For high availability checks>
    End
    #Redirect    "<url>"
    #Session     "<configure for session tracking>"
        #Type        IP|BASIC|PARM|COOKIE|HEADER
        #TTL         <seconds>
        #ID          <Parameter name for 'Type' PARM>
End

Service
    #URL          ".*"
    HeadRequire  "Host: .*www.server2.co.uk.*"
    #HeadDeny     "<pattern>"
    Backend
        Address      63.246.8.13
        Port         8002
        #Priority     <1 - 9>
        #Timeout      <default - 15 seconds>
        #HAport       <For high availability checks>
    End
    #Redirect    "<url>"
    #Session     "<configure for session tracking>"
        #Type        IP|BASIC|PARM|COOKIE|HEADER
        #TTL         <seconds>
        #ID          <Parameter name for 'Type' PARM>
End


# server3 configuration
##################################

Service
    #URL          ".*"
    HeadRequire  "Host:.*www.server3.com.*"
    #HeadDeny     "<pattern>"
    Backend
        Address      63.246.8.13
        Port         8003
        #Priority     <1 - 9>
        #Timeout      <default - 15 seconds>
        #HAport       <For high availability checks>
    End
    #Redirect    "<url>"
    #Session     "<configure for session tracking>"
        #Type        IP|BASIC|PARM|COOKIE|HEADER
        #TTL         <seconds>
        #ID          <Parameter name for 'Type' PARM>
End


# server4 configuration
#########################

Service
    #URL          ".*"
    HeadRequire  "Host:.*www.server4.co.uk.*"
    #HeadDeny     "<pattern>"
    Backend
        Address      63.246.8.13
        Port         8005
        #Priority     <1 - 9>
        #Timeout      <default - 15 seconds>
        #HAport       <For high availability checks>
    End
    #Redirect    "<url>"
    #Session     "<configure for session tracking>"
        #Type        IP|BASIC|PARM|COOKIE|HEADER
        #TTL         <seconds>
        #ID          <Parameter name for 'Type' PARM>
End


# server5 configuration
############################

Service
    #URL          ".*"
    HeadRequire  "Host:.*www.server5.com.*"
    #HeadDeny     "<pattern>"
    Backend
        Address      63.246.8.13
        Port         8006
        #Priority     <1 - 9>
        #Timeout      <default - 15 seconds>
        #HAport       <For high availability checks>
    End
    #Redirect    "<url>"
    #Session     "<configure for session tracking>"
        #Type        IP|BASIC|PARM|COOKIE|HEADER
        #TTL         <seconds>
        #ID          <Parameter name for 'Type' PARM>
End

Attachments:  
text.html text/html 15010 Bytes

Re: [Pound Mailing List] URL Rewriting Issues with Pound Version 2 and OpenACS
Robert Segall <roseg(at)apsis.ch>
2006-06-26 19:34:17 [ SNIP ]
On Sat, 2006-06-24 at 23:18 +0100, Richard Hamilton wrote:
> Further to last message. I have established the origin of the 'Please use 
> HTTPS' page - it is indeed a page returned by OpenACS when there is a 
> problem redirecting to https.
> 
> I have studied the code and it seems that it devises a redirect based upon 
> the port number. If the https port number is something other than 8443, the 
> server issues a redirect to a url created in the following way:
> 
> Url for redirect becomes: "https://${host}:${ssl_port}${url}"
> 
> Now the important thing to note here is that the variable ${host} takes its 
> value direct from the http host header, ${ssl_port} comes from a config file 
> and url is the relative url of the link.
> 
> So that means that the only explanation for this is that Pound must be 
> rewriting the host header as the redirect passes through.
> 
> What should happen is that an incoming request for 
> http://www.server.com/private/index should be intercepted (as it is for a 
> secure resource), and an http redirect to a url constructed as described 
> above. This redirect should therefore carry the url - 
> https://www.server.com:8443/private/index
> 
> The browser should now of course request that url direct with port 8443.
> 
> However, I think that Pound is rewriting this url on its way to the browser 
> to restore it to:
> 
> http://www.server.com/private/index
> 
> and this prevents the redirect from working as expected.

Your assumption might be correct, but I'd rather deal with hard facts.
So I suggest:

1. Install LiveHTTPHeaders in you Firefox. This will give you the full
conversation between the browser and Pound, including all the headers,
redirects and what not.

2. Install tcpwatch between Pound and the back-end server. This will
give you the full conversation from the back-end's point of view,
including all the headers and redirects.

3. Post here your logs, showing the original requests, the real back-end
responses and how Pound modified them.

With that information we'll have a basis for trying to understand what
exactly happens and why.
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-44-920 4904


Re: [Pound Mailing List] URL Rewriting Issues with Pound Version 2 and OpenACS
"Richard Hamilton" <ricky.hamilton(at)btopenworld.com>
2006-06-26 19:53:40 [ SNIP ]
Thank you Robert - I will do that and report back.

Regards
Richard.

----- Original Message ----- 
From: "Robert Segall" <roseg(at)apsis.ch>
To: <pound(at)apsis.ch>
Sent: Monday, June 26, 2006 6:34 PM
Subject: Re: [Pound Mailing List] URL Rewriting Issues with Pound Version 2 
and OpenACS


> On Sat, 2006-06-24 at 23:18 +0100, Richard Hamilton wrote:
>> Further to last message. I have established the origin of the 'Please use
>> HTTPS' page - it is indeed a page returned by OpenACS when there is a
>> problem redirecting to https.
>>
>> I have studied the code and it seems that it devises a redirect based 
>> upon
>> the port number. If the https port number is something other than 8443, 
>> the
>> server issues a redirect to a url created in the following way:
>>
>> Url for redirect becomes: "https://${host}:${ssl_port}${url}"
>>
>> Now the important thing to note here is that the variable ${host} takes 
>> its
>> value direct from the http host header, ${ssl_port} comes from a config 
>> file
>> and url is the relative url of the link.
>>
>> So that means that the only explanation for this is that Pound must be
>> rewriting the host header as the redirect passes through.
>>
>> What should happen is that an incoming request for
>> http://www.server.com/private/index should be intercepted (as it is for a
>> secure resource), and an http redirect to a url constructed as described
>> above. This redirect should therefore carry the url -
>> https://www.server.com:8443/private/index
>>
>> The browser should now of course request that url direct with port 8443.
>>
>> However, I think that Pound is rewriting this url on its way to the 
>> browser
>> to restore it to:
>>
>> http://www.server.com/private/index
>>
>> and this prevents the redirect from working as expected.
>
> Your assumption might be correct, but I'd rather deal with hard facts.
> So I suggest:
>
> 1. Install LiveHTTPHeaders in you Firefox. This will give you the full
> conversation between the browser and Pound, including all the headers,
> redirects and what not.
>
> 2. Install tcpwatch between Pound and the back-end server. This will
> give you the full conversation from the back-end's point of view,
> including all the headers and redirects.
>
> 3. Post here your logs, showing the original requests, the real back-end
> responses and how Pound modified them.
>
> With that information we'll have a basis for trying to understand what
> exactly happens and why.
> -- 
> Robert Segall
> Apsis GmbH
> Postfach, Uetikon am See, CH-8707
> Tel: +41-44-920 4904
>
>
> -- 
> To unsubscribe send an email with subject 'unsubscribe' to pound(at)apsis.ch.
> Please contact roseg(at)apsis.ch for questions.
>
http://www.apsis.ch/pound/pound_list/archive/2006/2006-06/1150319524000/1151343257000
> 


MailBoxer