thanks roseg

pound(at)apsis.ch schreef:[...]

On Wed, 2006-12-06 at 05:39 -0800, Rachel Florentine wrote:[...]

Please forgive my curiosity, but how large is a teraflop disk?
[...]

...which certainly won't copy all that much.
[...]

Copying won't affect the source, so it must be something else. See your
logs for error messages.[...]

Hola Francisco:
[...]

In case it helps, attached is a Perl-based HAPort server written for
Windows which opens and closes the high availability port after checking
status against a database. It runs as a service in back-end machines.

It should be easy to modify for Unix and for HTTP requests, instead of
database queries. The script uses some functions from an external
library (IODBUpd.pm), but they are only related to log file and database
connection/query handling. I suppose you can figure out what they do by
their names.

Saludos,

 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.

On Wed, 2006-12-20 at 19:01 -0500, Joe Gooch wrote:[...]

I think you didn't follow it all the way through: if need_rewrite()
succeeds the address gets rewritten with https.

The mechanism is intended to work with several scenarios:

1. no rewriting wanted (trivial).

2. Pound is used with a brain-dead back-end that insists on prepending
http even though the connection is https. If default ports are used then
we compare addresses only (http default to port 80, https to port 443).

3. two back-ends are used, one for http and one for https, with
redirects between them. Compare address and port to tell them apart.

...and finally don't forget that some redirects should not be changed at
all.[...]

> -----Original Message-----[...]
once[...]
will[...]
Listener[...]
an[...]
we[...]
non-standard[...]
doing[...]
http://proxy:8443/MyApp/[...]
address,[...]
SSL[...]
encountered[...]
my[...]
then[...]
443).[...]
at[...]

*nod* I get that.  That's why the change I made was in the needs_rewrite
function.

If I'm connected to the server with SSL, on a SSL listener, and the
redirect has the correct port for my SSL listener but the protocol of
http, that is incorrect.  If it comes back with port 80 and http, fine.
But since the web server backend is plain http, and the Host line
contains the SSL port, the redirect is incorrect and needs to be
rewritten.

Joseph Gooch
Sapphire Suite Product Manager
K12 Systems, Inc.
(866) 366-9540

> -----Original Message-----[...]
once[...]
will[...]
Listener[...]
an[...]
we[...]
non-standard[...]
doing[...]
http://proxy:8443/MyApp/[...]
address,[...]
SSL[...]
encountered[...]
my[...]
then[...]
443).[...]
at[...]


I think perhaps the port check against the listener exists for a good
reason...If I had a backend on the pound server that was on port 80 and
443 for my main site, and another on 8080 that pointed to Zope, for
instance, and I wanted to redirect from one backend to another, I would
need to make sure I'm only rewriting the request if it matches the
listener from which the original request initiated.

In that case, take option 1 off of my original email.  However, I
believe option 2 still has merit.  The comparison of the ports is all
well and good, unless the Host line includes an explicit port number
(which is based on the Listener's port, not the backend's port).  The
backend will always rewrite with the backend protocol (unless it's done
in PHP or programmatically... the web server will likely always use the
connection protocol) so we have two scenarios.

1) The Redirect matches the listener address, and the port doesn't
match.  In this case RewriteLocation would rewrite it. (Possibly
breaking the Zope example above... but I'm not using this and don't know
why you wouldn't just use a Service entry or something similar)  This is
the behavior currently in the code.
2) The Redirect matches the listener address, and the port DOES match,
but the protocol is wrong.  If the port is *explicitly* supplied in the
Host: line, i.e. if I explicitly went to
https://poundserver.domain.com:443/
and my browser passes the Host line
verbatim, pound will use 443 in the check and find that it matches with
my SSL listener.  However, the server sent back http.

Thus in scenario 2 it is appropriate to check that the redirect protocol
actually matches with the Listener's protocol.  If it doesn't,
need_rewrite() should return true.

Joseph Gooch
Sapphire Suite Product Manager
K12 Systems, Inc.
(866) 366-9540

On Thu, 2006-12-21 at 14:05 -0500, Joe Gooch wrote:[...]

Some back-ends do, others don't...

The problem is what the back-end does. Imagine a request coming over
HTTPS to Pound, which sends it on to the back-end. In this case the Host
header will include https. Now the back-end replies with a redirect.
What shows in the Location header? We have seen three real-life
possibilities:

1. The back-end accepts the Host value and issues a redirect to it (i.e.
https://pound.address).
2. The back-end says 'I listen on http, so that's what I redirect to,
but with the address of the original host' (http://pound.address).
3. The back-end issues a redirect to itself (http://back.end.address).

As you correctly remarked the issue is further complicated if you have
both http and https, with redirects between them.[...]

[...]
good[...]
and[...]
would[...]
all[...]
The[...]
done[...]
the[...]
Host[...]
(i.e.[...]

In my experience, the host line doesn't ever contain the protocol.

RFC2616 shows the grammar for the host header as:

Host = "Host" ":" host [ ":" port ] ; Section 3.2.2

And in my experience, it will only ever have a hostname, ip, ip:port, or
hostname:port.

Thus, what you're saying, the header will include https, is not what I
see in practice.  If a request is going to poundserver.domain.com via
https or http and no port is specified, both requests will have the same
Host header, poundserver.domain.com.  It's the whole reason I use
Front-end-https:on in my pound.cfg.  If a request is going to
poundserver.domain.com:443 via https, the Host header has
poundserver.domain.com:443.

So I don't see how #1 in your scenario could ever happen.  Backends
aren't https.  Unless the redirect is entirely relative, it wouldn't
know if the frontend is http or https, unless the redirect is done in
code.  The web server is going to have to redirect to the Host line or
the backend address, and it should maintain the protocol as http,
because it doesn't know there's a proxy, nor would it have any way of
knowing, and the request came in via http.

You can reproduce my issue with a single listener.  I'm not doing any
redirects.  This is just standard, "The user went to a directory without
the trailing slash and we're going to redirect them to the same place"
behavior that just about every web server supports.

I think in the spirit of the check in needs_rewrite, where we're
checking the redirect to make sure the backend did it right, the
protocol check is necessary and prudent.

Joseph Gooch
Sapphire Suite Product Manager
K12 Systems, Inc.

On Wed, 2006-12-27 at 12:17 -0500, Joe Gooch wrote:[...]

You are right of course, I was thinking of the Location header. My
mistake.
[...]

One more question: in your case you do a simple http to http redirect,
(rather than https). How would this work?[...]

> -----Original Message-----[...]
ip:port, or[...]

Ahh, well, then you'd be right. :)
 [...]
I[...]
via[...]
same[...]
in[...]
or[...]
of[...]
any[...]
without[...]
place"[...]

Well, if the listener is a HTTP listener, and the backend redirects to a
HTTP protocol, then there are some possibilities.
1) The port number of the redirect is not specified in the Host header,
or in the redirect, so it defaults to 80.  Since the protocol of the
listener is http and so is the backend, the protocol will match.  If the
listener is on port 80, needs_rewrite is false.  (which is fine)  If the
listener is not on port 80, needs_rewrite is true, because the port
doesn't match.  (which is also fine)
2) The port number of the redirect is specified explicitly in the Host
header as port 80.  Everything above still holds true, so again, no big
deal.
3) The port number of the redirect is specified explicitly in the Host
header as a non-standard port.  (Which is how I believe a browser would
handle non-standard ports)  needs_rewrite will compare the port against
the listener, find they match, and return false.  (which is fine)

With the patch (attached), the above 3 cases would proceed in exactly
the same manner, because all I've done is compare the protocol against
the listener, and in each case, http would match a listenhttp directive,
so it would be just fine.

You are correct in that the problem manifests itself on HTTPS
connections to pound, since the mismatch of the listener protocol to the
backend is what causes the issue.  It looks like the "port doesn't
match" check was put in to find this type of thing, (or that as a side
effect it fixed them for standard SSL ports), since a backend http
redirect would usually be on port 80, which wouldn't match the listener.
This just goes one step further and says if the port DOES match the
listener, let's just be really sure that the protocol matches too.

Thanks for indulging me!

Joseph Gooch
Sapphire Suite Product Manager
K12 Systems, Inc.
(866) 366-9540