Re: ssl branch compile problems

Henk-Jan Kloosterman wrote:

> > https_port 10.0.1.43:443 cert=/path/to/cert1.pem
> > https_port 10.0.1.44:443 cert=/path/to/cert2.pem
> > https_port 10.0.1.45:443 cert=/path/to/cert3.pem key=/path/to/key3.pem
> >
> > (if only the certificate is specified then it is assumed it is a
> > combined certificate/key file)
>
> I think for a lot of people this would be the best solution. Must there not
> be some kind of "listen" host?

What do you mean by "listen" host?

> These would be nice options for me (I could live with a certificate per
> domain)
> It would be nice to be able to run 2 identical informayion resources, and
> then
> squid checks, if they are available, or with an external program, which one
> has the lightest load.

This you can do today, either by running the servers as peers, or via a
redirector helper.

What is yet missing from Squid is if you split the content on URL-path,
mapping it to different information resources using a slightly different
URL-path on the real server. When you do this Squid won't rewrite any
links served by the real server to match the virtual URL mapping.

Example mapping:
   www.example.com/se/ -> www.example.se
   www.example.com/de/ -> www.example.de
   www.example.com/uk/ -> www.example.co.uk
(or the other way around if so preferred)

With link rewriting in place, it does not need to be visible to the
requestor that such rewrites are taking place. If the origin server
outputs a absolute URL (such as www.example.se/some/file) the link
rewriting will transform the HTML code to give the link
www.example.com/se/some/file to the requestor..

This becomes more important when the URL targets are internal servers,
not directly reachable by the clients. Such as when you build a extranet
service which collects information from a number of internal server.

--
Henrik Nordstrom
Squid hacker