--On Mittwoch, 24. September 2003 14:28 +0200 Robert Segall
<roseg(at)apsis.ch>
wrote:
 [...]

Hello Robert,

Rewriting a hostname in the response with the ip-address of the
proxy itself breaks at least HeadRequire Host ".*whatever\..+"
which wont match anymore.

And even on non-http-header based systems this will prevent the
client from sending the cookie, and with frames all cross-domain
restrictions apply, javascript bombs.

Location-rewriting seems to be approriate in the case of HTTPS-
requests, but even in then the sudden change of the domain to a
ip-address will void the certificate and the user presented with
confusing dialogs.

For those reasons any rewrite has to be done to domains, and never
the plain ip.

I suggest introducing a new configuration option:

RewriteLocation	"mypound.example.com"

This allows cookies, javascript ans ssl-certificates to work, and
no rewriting should be done unless explicitely specified to keep
up the compatipility with 1.4.

I have two chained instanced of Pound with portforwarding between
(dont ask why...) and dont want anything to mess with the 30x.

Roland

--On Donnerstag, 25. September 2003 15:32 +0200 Roland
<list-pound(at)openrbl.org> wrote:
[...]

While thinking some more about the location-rewrite there is still
a problem how Pound could reliably determine wether the redirect
issued by the backend should in fact point back to itself as there
is no time for sending dns-requests, and what the public hostname(s)
of Pound are as seen by the client.

I'll update my suggestion:

RewriteLocation "backend.example.com" "mypound.example.com"
RewriteLocation "10.0.0.1" "mypound.example.com"

whenever the Location after http[s]:// matches the first argument.
This would be something like a hardwired rewrite-table.

The current hostname as seen by the browser (mypound.example.com)
could be also taken from the host-header of the request.
This header is actually the only 'authoritative' information about
the hostname as seen by the client. If the client does not provide
a host-header fallback to the ip could be considered, such clients
(M$-worms) are not capable of ssl, cookies or javascript anyway.

A RewriteLocation with only one argument could fill in the currently
used hostname on the fly, and provide flexibility for cases where
multiple subdomains or hostnames point to the same server, a simple
example would be 'www.example.com' and 'example.com'.

Roland

On Thursday 25 September 2003 16:53, Roland wrote:[...]

I think that taking the host name from the Host header would be great, and it 
would be the prefered solution, but what do we do with old clients? HTTP 1.0 
does not _require_ a Host header at all! Granted this would not be a problem 
with most browsers, but could fail badly with a bunch of command-line clients.

I am not really enthusiastic about a hard-wired (fixed) table - it would 
defeat virtual hosts.

The only alternative I can think about now is to add a "default" host in the 
UrlGroup: given that that is where you would normally separate virtual hosts 
I would suggest the following bahaviour:

- by default Pound rewrites the Location header with its own protocol 
(SSL/non SSL) and the contents of the Host header.
- this can be overriden by a global - i.e. outside of a UrlGroup - 
RewriteLocation directive (protocol as above).
- these can be both overriden by a RewriteLocation directive in a UrlGroup 
(protocol as above).
- in the absence of both Host and RewriteLocation of either kind no rewriting 
occurs.
- rewriting is conditional upon the Location host being "known" in the sense 
currently implemented.

I'd appreciate the group's views on these ideas.[...]

--On Donnerstag, 25. September 2003 17:25 +0200 Robert Segall
<roseg(at)apsis.ch> wrote:
[...]
it [...]
1.0 [...]
problem [...]
clients.
[...][...]

There is no issue with clients which do not send a host-header,
just rewrite those to the external ip-address of the proxy itself.
It might be tricky to get the right address if bound to multiple
addresses though.

Hostname-based configurations will never receive such a request
in the first place and can not possibly respond with a 30x.
There is rarely any client which does not send a host except some
worms and formmail-scanners, and for shure no one which is able
to do ssl, cookie or java/script which could break.
[...]

Its simple, probably easy to implement in the code and does not
confuse the administrator too much.
But 'intelligent' rewriting based on the host-header in current
request would be great.
 [...]

I am for whatever allows the -current feature to be turned off ;)

Roland