rob at exitexchange
Jan 25, 2006, 3:04 PM
Post #3 of 5
Theo Schlossnagle wrote:
> Rob Bloodgood wrote:
>> I would really love to figure out how this directive is supposed to be
>> I'm setting up backhand, and I have set up a pair of servers to share
>> the load of the machine that's getting backhand on it.
>> (I'm already using mod_log_spread, presently I'll be setting up
>> The problem I have, which I'm not sure will be solved until I get
>> wackamole going, is that doing backhand by proxy keeps my "main" server
>> too busy, because instead of just handling (too many) requests, It's
>> handling the same number, but also proxying some of them via backhand.
>> So when I discovered HTTPRedirectoToName, I thought, this is cool, I can
>> just redirect instead of proxy!
>> Only... it doesn't.
>> I have count1, count3, count4 boxen in my backhand cluster. count1 is
>> the "main" box that I'm trying to load balance. I want count1 to
>> redirect requests over to count3/count4 based on load, etc. So I have:
>> <LocationMatch "/backhanded/.+">
>> Backhand byAge 2
>> # Backhand removeSelf
>> Backhand byLoad
>> Backhand HTTPRedirectToName %1S.%1H
>> # Backhand HTTPRedirectToIP
>> BackhandLogLevel +netall,+mbcsall,+dcsnall
>> # BackhandLogLevel +dcsnall
>> Now, looking at the surface, this should work great. However:
>> [Wed Jan 25 13:42:31 2006] [notice] Func executed for (null)
>> [HTTPRedirectToName(%1S.%1H)] (3 -> 0)
>> [Wed Jan 25 13:42:31 2006] [notice] New server list: [ ]
>> [Wed Jan 25 13:42:31 2006] [notice] All funcs executed -> local
>> I went ahead and looked at the source of builtins.c. From what I can
>> tell, it takes the incoming Host: header and uses it to assemble a
>> HOWEVER, the logic in HTTPRedirectToName() says:
>> 1. do hostname stuff with *ME*, first. (%1S.%1H) if the name matches
>> my actual hostname, never mind.
>> 2. do hostname stuff with the server we selected to backhand to.
>> assemble a hostname out of server plus the domain, (%1S.%1H) and then
>> redirect to that host.
>> point 2 is what I was shooting for.
>> as far as point 1:
>> What?????? It will *always* match, and then clear the server list,
>> unless the request contains a Host: header that... what, refers to a
>> different machine? Is that even possible?
>> ... Instead of seeing whom to redirect to and using HTTPRedirectToName()
>> to assemble a full hostname to send to, the logic says, if I am me, and
>> the Host: header is to me, then I don't backhand.
>> It falls off and prevents doing anything useful before the actual,
>> desired behavior: pick a host that's not me (if conditions are met) and
>> redirect to it (instead of proxying).
>> Have I completely missed the point of this directive, or used it wrong?
> Not missed the point. It prevents the possiblity of an d enless set of
> redirects. where you just bounce back and forth all the time.
> The goal is to go to www.exmaple.com and then have that be no-one's
> hostname. The three hostnames are www.de.exmaple.com,
> www.us.example.com and www.jp.exmaple.com. Once you hit
> www.XX.exmaple.com, that logic will prevent you from yet again being
> Perhaps you already figured that out, I misunderstood and there is a
> bug? Certainly possible. It is one of the least used features in
OK, well then I think there's some kind of logic flaw. I can see the
step of removing oneself to prevent endless redirects, but that should
happen *after* the host intended gets determined.
Would it be effective to add to err_headers_out the Backhand-Proxied-For
header, so that the incoming (redirected) request can use that to flag
bypassing additional redirects?
That way, the "part 2" of the logic (starting at line 323 of builtins.c
in the 1.2.2 distribution) can be processed after the "Oh wait, I'm
already in the chain" fall through, allowing original requests to be
so my incoming Host: count.exitexchange.com gets parsed with %1S.%1H as
(count3, chosen by backhand).exitexchange.com, and backhand adds the
appropriate header to err_headers_out.
Oh wait, that's not quite right either, because the client won't forward
that header on the next request. Grr. So I guess I don't know what a
good solution would be.
(Please forgive me if the identifier isn't exactly err_headers_out... I
work extensively with mod_perl, so I understand the apache API but not
all of the function names are the same.)
Oh and while I'm at it, for the record, there is an issue with module
loading order with mod_perl. As per (some instruction I found), I put
AddModule mod_backhand.c as the first line after ClearModuleList.
However, that put the Type checker in the wrong order, so that mod_perl
handlers always translated as perl-handler, not backhand-redirect.
Placing the directives in this order fixes it:
backhand-users mailing list
backhand-users [at] lists