Mailing List Archive: HTTPRedirectoToName

HTTPRedirectoToName

Jan 25, 2006, 1:57 PM

Post #1 of 5 (12701 views)

I would really love to figure out how this directive is supposed to be
useful.

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 wackamole).

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
</LocationMatch>

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 hostname.

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?

Or should I just wait until I get wackamole going and eliminate the
issue from that direction?

Thanks very much in advance.

L8r,
Rob

_______________________________________________
backhand-users mailing list
backhand-users@lists.backhand.org
http://lists.backhand.org/mailman/listinfo/backhand-users

Re: HTTPRedirectoToName [ In reply to ]

jesus at omniti

Jan 25, 2006, 2:16 PM

Post #2 of 5 (12214 views)

Permalink

Rob Bloodgood wrote:

>I would really love to figure out how this directive is supposed to be
>useful.
>
>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 wackamole).
>
>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
></LocationMatch>
>
>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 hostname.
>
>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
redirected.

Perhaps you already figured that out, I misunderstood and there is a
bug? Certainly possible. It is one of the least used features in
mod_backhand.

--
// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// Ecelerity: Run with it. -- http://www.omniti.com/

_______________________________________________
backhand-users mailing list
backhand-users@lists.backhand.org
http://lists.backhand.org/mailman/listinfo/backhand-users

Re: HTTPRedirectoToName [ In reply to ]

rob at exitexchange

Jan 25, 2006, 3:04 PM

Post #3 of 5 (12197 views)

Permalink

Theo Schlossnagle wrote:
> Rob Bloodgood wrote:
>
>> I would really love to figure out how this directive is supposed to be
>> useful.
>>
>> 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
>> wackamole).
>>
>> 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
>> </LocationMatch>
>>
>> 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
>> hostname.
>>
>> 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
> redirected.
>
> Perhaps you already figured that out, I misunderstood and there is a
> bug? Certainly possible. It is one of the least used features in
> mod_backhand.

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
backhanded.

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:
AddModule mod_perl.c
AddModule mod_backhand.c

L8r,
Rob

_______________________________________________
backhand-users mailing list
backhand-users@lists.backhand.org
http://lists.backhand.org/mailman/listinfo/backhand-users

Re: HTTPRedirectoToName [ In reply to ]

rob at exitexchange

Jan 25, 2006, 5:30 PM

Post #4 of 5 (12236 views)

Permalink

Rob Bloodgood wrote:
>>> 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
>>> </LocationMatch>
>>>
>>> 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
>>>
...
>>> 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
>> redirected.
>>
>> Perhaps you already figured that out, I misunderstood and there is a
>> bug? Certainly possible. It is one of the least used features in
>> mod_backhand.

OK, there was a missing piece to my story. The host named count1 is
actually named count, and I was "getting to it" to name it count1.
Well, I thought about that. The server that I'm renaming to count1 is
getting all its hits with the Host: count.example.com. So if I change
the apache config so that the local server name is count1, then I have a
chance at the redirect logic letting me through.

So I tried it.

at first, I was disappointed again. but I had played with my module
loading order a little bit, since I had thought about that while
composing my earlier message. I had moved mod_perl.c and mod_backhand.c
to be the first two modules in the list.

Since I was having issues, I reversed that step, placed those two
AddModule directives back at the end of the list, and it started working!

*AND*, my supposition was correct! changing the internal server name to
count1 when the incoming Host: headers all say count.domain.com made
redirection start working for me.

Unfortunately... that does mean that I end up with one additional
redirect for requests I handle "myself" (where redirects to count1
happen to be the same box as the "Host: count"). But that should be
pretty painless in terms of load.

Comments?

L8r,
Rob

_______________________________________________
backhand-users mailing list
backhand-users@lists.backhand.org
http://lists.backhand.org/mailman/listinfo/backhand-users

Re: HTTPRedirectoToName [ In reply to ]

jesus at omniti

Jan 25, 2006, 5:35 PM

Post #5 of 5 (12210 views)

Permalink

On Jan 25, 2006, at 8:30 PM, Rob Bloodgood wrote:

> Rob Bloodgood wrote:
>>>> 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
>>>> </LocationMatch>
>>>>
>>>> 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
>>>>
> ...
>>>> 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
>>> redirected.
>>>
>>> Perhaps you already figured that out, I misunderstood and there is a
>>> bug? Certainly possible. It is one of the least used features in
>>> mod_backhand.
>
> OK, there was a missing piece to my story. The host named count1 is
> actually named count, and I was "getting to it" to name it count1.
> Well, I thought about that. The server that I'm renaming to count1 is
> getting all its hits with the Host: count.example.com. So if I change
> the apache config so that the local server name is count1, then I
> have a
> chance at the redirect logic letting me through.
>
> So I tried it.
>
> at first, I was disappointed again. but I had played with my module
> loading order a little bit, since I had thought about that while
> composing my earlier message. I had moved mod_perl.c and
> mod_backhand.c
> to be the first two modules in the list.
>
> Since I was having issues, I reversed that step, placed those two
> AddModule directives back at the end of the list, and it started
> working!
>
> *AND*, my supposition was correct! changing the internal server
> name to
> count1 when the incoming Host: headers all say count.domain.com made
> redirection start working for me.
>
> Unfortunately... that does mean that I end up with one additional
> redirect for requests I handle "myself" (where redirects to count1
> happen to be the same box as the "Host: count"). But that should be
> pretty painless in terms of load.
>
> Comments?

You've achieved the intended use-case:
http://www.backhand.org/ApacheCon2000/EU/img23.htm

Glad you got it working.

_______________________________________________
backhand-users mailing list
backhand-users@lists.backhand.org
http://lists.backhand.org/mailman/listinfo/backhand-users