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 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
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |