Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
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-
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |