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

[Dan Ritter]

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?

-dsr-