Trying to learn something but not sure what to Google...

[Jarod Wilson]

On Mon, Sep 13, 2010 at 1:41 PM, Dan Ritter <dsr-mzpnVDyJpH4k7aNtvndDlA at public.gmane.org> wrote:
> On Mon, Sep 13, 2010 at 01:26:07PM -0400, Jarod Wilson wrote:
>> On Mon, Sep 13, 2010 at 8:11 AM, Edward Ned Harvey <blu-Z8efaSeK1ezqlBn2x/YWAg at public.gmane.org> wrote:
>> >> From: discuss-bounces-mNDKBlG2WHs at public.gmane.org [mailto:discuss-bounces-mNDKBlG2WHs at public.gmane.org] On
>> >> Behalf Of Jarod Wilson
>> >>
>> >> ^ Note that there is no specific mention of NAT here. ^
>> >> etc.
>> >
>> > Apparently we're just arguing about semantics here.  Because we both agreed
>> > on the actual points.
>>
>> Mostly, yes.
>>
>> > The actual points were:  With just a router, you cannot take inbound
>> > requests on some IP address port 80, and then direct the traffic to
>> > different internal servers based on which page was requested.  There must be
>> > a web server or something that understands http, which is the NAT target,
>> > which could then either proxy or redirect the traffic to multiple internal
>> > servers.
>>
>> Here's why its mostly. You appear to still be insisting that you
>> *must* NAT. I'm insisting that with a capable enough router platform,
>> no NAT is required at all, you do the proxying on the router. :)
>
> If you have an ethernet packet coming in, and you do all your forwarding
> based on the ethernet header, you cannot solve this scenario's problem. So
> you give up on *switching* (L2), and kick it up a level.
>
> If you have a TCP packet coming in, and you do all your forwarding based
> on the TCP and IP headers, you cannot solve the problem of "where should
> this packet go" in this scenario. So you give up on *routing* (L3), and
> kick it up a level.
>
> Now you need a decision-maker based on L4 or higher protocols, such as
> HTTP1.1. (Note that if you are receiving an HTTP1.0 packet, you are out of
> luck because that protocol doesn't include the FQDN in the request.) This
> is called a *proxy*, and may include other features such as load balancing,
> logging, HTTP/SSL termination, and so forth.
>
> To get back to the original poster's request: it needs clarification as to
> what they want to have happen. If they just want to host multiple domain
> names with different content on one machine, that's what name-based
> virtual hosts are for. If it is important that different names go
> to different machines, then either they have to acquire multiple IP
> addresses or do some proxying.
>
>
> Have we beaten this equine-shaped patch of earth sufficiently
> flat now?

I'm not sure, I think I just saw it twitch again.

-- 
Jarod Wilson
jarod-ajLrJawYSntWk0Htik3J/w at public.gmane.org