Ok, until now the latest beta behaves ok.
Regards,
Sérgio

-----Original Message-----
From: Robert Segall [mailto:roseg(at)apsis.ch] 
Sent: Monday, January 23, 2006 1:12 PM
To: pound(at)apsis.ch
Subject: [Pound Mailing List] 2.0 Release

Unless someone comes up with additional problems or objections we would
like to release the "official" 2.0 by the end of this week. The code is
(essentially) that of the latest beta.

Please let us know if you found out anything that still needs fixing.[...]

> Unless someone comes up with additional problems or objections we
would[...]

We're running 2.0-0.b6_1 for quite some time now on two production servers
without any problems. We also don't see any memory leaks anymore like the
one we saw with 1.x.

Simon

Are you going to include any init scripts?
If you want me to revise anything please tell.
Regards,
Sergio Freire

-----Original Message-----
From: Robert Segall [mailto:roseg(at)apsis.ch] 
Sent: Monday, January 23, 2006 1:12 PM
To: pound(at)apsis.ch
Subject: [Pound Mailing List] 2.0 Release

Unless someone comes up with additional problems or objections we would
like to release the "official" 2.0 by the end of this week. The code is
(essentially) that of the latest beta.

Please let us know if you found out anything that still needs fixing.[...]

On Mon, 2006-01-23 at 16:18 +0000, Sergio Freire wrote:[...]

Thanks for the offer, but we do not include init scripts or anything of
the sort. Given that each system is different we feel it is best to
leave that to the packagers (Debian is not RH is not Suse is not FreeBSD
is not OpenBSD is not Solaris is not AIX is not OS/X is not Cygwin is
not OpenVMS is not Tru64 is not zOS - you get the idea).[...]

Hello,

Apologies that it has taken so long to reply, I have been on holidays
for six weeks.  We recently went live with Pound 1.9.x on our site
http://www.globalhand.org.  We are in
the process of adding a number of
features to Pound.

A key feature we require is the ability to failover to a server, if and
only if all backend servers are dead.  We require this functionality to
bypass our inline cache if it fails.  We had considered using cached and
non-cached access to our site as backends, the cached access being
weighted highly whilst the non-cached access being weighted low.  This
is not possible in our case as some of our pages are very intensive to
create and relatively static, the performance penalty is too great.

Additionally, we need to set a <meta> tag in the head of the error pages
so we can perform redirection to the real error page (we have nice
friendly nice looking error pages served from Apache) if there is an
error in Pound.  We have noticed that specifying a Err4xx page in the
configuration file does not allow control of all the HTML served during
an error, Pound adds its' own head, title and HTML to the page.

Initially we will add these features to the 1.9.x branch as we are most
familiar with the source, and will port it to 2.x once it has stabilised
(I see 2.x is about to leave beta status) and we have done sufficient
testing.

Could you post somewhere, or email us the configure.in and associated
files so we can add additional configuration options.  We are
considering a '--no-ssl' or similar option to remove all SSL code along
with a few other options.


				Many thanks,


				Tom Pike

On Mon, 2005-12-12 at 12:56 +0100, Robert Segall wrote: [...][...]

On Thu, 2006-01-26 at 23:28 +1100, Tom Pike wrote:[...]

The emergency back-end and/or redirect are planned features for 2.1.
Right now we concentrate on getting 2.0 out - hopefully this week. In
any case I suggest you try working on the 2.x series, as 1.x are
definitely EOL and we won't be making any new releases there.

As to specifics: we plan on adding an Emergency back-end directive,
which can be either a real back-end or a redirect. This would be
activated iff all back-ends for a given Service are dead.

The 4xx error won't help you. It is meant only as an indication for the
client that it has exceeded a Pound limit (specifically the length of a
request URI), and it does not indicate a problem on the back-ends. A
possible change there would be to take a full HTML file rather than a
text file/string. I would appreciate some opinions on this.

Finally a --no-ssl option would be difficult to do, as all I/O is done
via the BIO functions, even for regular HTTP. So at best you could
disable HTTPS, but that won't remove the dependency on the OpenSSL
library.[...]