Re: Redirection to Other IP Addresses
Jack Firth <jackhfirth@gmail.com> Thu, 01 August 2019 07:18 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C463120026 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 1 Aug 2019 00:18:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.497
X-Spam-Level:
X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, GB_VISITOURSITE=2, HEADER_FROM_DIFFERENT_DOMAINS=0.201, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 018PQW4hEmbp for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 1 Aug 2019 00:18:46 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74A3F120025 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 1 Aug 2019 00:18:46 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1ht5KG-0003Ii-G3 for ietf-http-wg-dist@listhub.w3.org; Thu, 01 Aug 2019 07:16:36 +0000
Resent-Date: Thu, 01 Aug 2019 07:16:36 +0000
Resent-Message-Id: <E1ht5KG-0003Ii-G3@frink.w3.org>
Received: from uranus.w3.org ([128.30.52.58]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <jackhfirth@gmail.com>) id 1ht5KD-0003HU-Op for ietf-http-wg@listhub.w3.org; Thu, 01 Aug 2019 07:16:33 +0000
Received: from www-data by uranus.w3.org with local (Exim 4.89) (envelope-from <jackhfirth@gmail.com>) id 1ht5KD-0007A2-IQ for ietf-http-wg@listhub.w3.org; Thu, 01 Aug 2019 07:16:33 +0000
Received: from mimas.w3.org ([2603:400a:ffff:804:801e:34:0:4f]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <jackhfirth@gmail.com>) id 1ht5Bl-0004q2-4Q for ietf-http-wg@listhub.w3.org; Thu, 01 Aug 2019 07:07:49 +0000
Received: from mail-qk1-x72b.google.com ([2607:f8b0:4864:20::72b]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <jackhfirth@gmail.com>) id 1ht5Bi-0000rS-U7 for ietf-http-wg@w3.org; Thu, 01 Aug 2019 07:07:49 +0000
Received: by mail-qk1-x72b.google.com with SMTP id s22so51231742qkj.12 for <ietf-http-wg@w3.org>; Thu, 01 Aug 2019 00:07:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mXMYra2xQk6ROLVOSa1/naDZFIMotfo90jEuXKN3gj8=; b=qppEzOsxpQ+WHvyWlJKr/FoQ/sqaATyEMalPcKAXoZEBG9suTlJRkOUgMcyQsJCvy5 RS5dfiXySflx/qk3EgCpTbJ+NANXR9q7wVtFtSLrJXK0lZaoCfNLaydYnnXFu/x2VJx8 rqIXPgygFRnuyHkzludrPbWrXBxGPTcsjBcclOdIzyv9mCUqp1PuqU62jDvwr73iAKAr ZriVumB7mvik5Y2qvD63wNdTiJ89edzjg9m+bpVaKcQDetLtqX3H1aEZgsG2k84FrSNx ZHxMM1AgTWyLI8zLCpLNdujlAL0es/r6CvJk5nnx4SzAWiPD+1qPe+aU/mYVHBG/qRN/ S2bQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mXMYra2xQk6ROLVOSa1/naDZFIMotfo90jEuXKN3gj8=; b=Qw7Yk3w2NcGzjdcBMA/8bi1nYG/5/Irt90SbUkARicttkjNW5MvV6On4xCFtpVCr5i /HzrC8635mShwKngd9Z64onFJvJ4FzaPgFNyGYBKQ6/t+pnR550Bwt0Leb35SkUc2t57 BjiX3mqmsiaFRenW9Z1Htm6FFs61k4ldvcJpqc4iuwVNaYXFlA9K8PpN5/GIpLMUrjwu WISBKfVr8zjeTnbxpw3v4pqEaA4J2u/4OuA9vDQyNiVewyckFlEs64Ho7rQ92xNaRtD4 MobZbDNqkv0hcAeGFIAx4qKHejPKvMkTTPfbFZ8CxJFhyL9wAIdylFIlfciH9UvN9IYO t8pw==
X-Gm-Message-State: APjAAAUQpLcTuSqvSVQl89KA/OL7N3dGfLRA5GyOshhon2u2hRbZ2hvV Z0kc/15fetHjd6vvyvGJpo3qAzTSkGx6Toz/vD7m9C9N
X-Google-Smtp-Source: APXvYqxUP3YLvhr1BzAi5nZK8lhgoks+tIb/ToTtsebHrzGLDqap6am3wXlUlKQKcnG4kwQYtFanWdLqmyDMYkWVBes=
X-Received: by 2002:a37:a603:: with SMTP id p3mr86315343qke.297.1564643245606; Thu, 01 Aug 2019 00:07:25 -0700 (PDT)
MIME-Version: 1.0
References: <CAFifEMLOHp5=OqUXZbg_WKNQmNsTW3Bg5P4btJdX06CF=Wi2AA@mail.gmail.com> <d9b03ef6-9c8c-1eb2-7f74-014f9703475d@gmx.de> <CAJ_4DfQifbJJ7owfrgUUOqXimL-KQkb4-1f_Qp6+CMjhYC1bbg@mail.gmail.com> <CAFifEMJPZd9CGghi_MJ1Hrcq7TJNnkV6yH-EKtrrfaQmStS4Ug@mail.gmail.com> <b09ab672-f512-52bc-6c28-7df55919a846@gmx.de> <CAFifEM+TXtsxTt-NcH+hQomEAYZmMTW_kPxXvQB69eM4KgGf7g@mail.gmail.com> <d4d25ceb-09b5-72ff-6c36-7fdfc2796b15@gmx.de> <CAFifEMKff11nmJZgE1RGWT8qH6SKsO2tqWCF9vQsvF5=BMeQgg@mail.gmail.com> <45C10C32-DA87-4AE3-9082-DAAFD5D9C412@vcontractor.co.za> <CAHbrMsAE1ZezM5U_b2s3juc4OC0LJDOpyHfek7Pu2AaQcXpf8A@mail.gmail.com> <CAJU8_nWP63pT08X4QkUmk6KT_U98LjiFvNaTNg5ZtVMG3AFiFg@mail.gmail.com> <CAFifEMLnSB5SYb_q0toTE3Xy1i56=14ki=__91Phc76HHL+ZhQ@mail.gmail.com> <f05b5157-f068-1e03-8422-36d0425a32a5@treenet.co.nz> <CAFifEMLQXUSHKOjKN9JR87ht1UUvf-1AEWKNmuKeOqKyzjT28Q@mail.gmail.com> <CAJEGKNtWvXyrFLU0KW-rqN1qd-PLOqobjx1o6kRcH27_O9Ri7Q@mail.gmail.com> <CAFifEMKhjU=EmMj6yyVN5D1aSfCVi9HAWgE-Ebzu8NscKQpv_w@mail.gmail.com> <CAJEGKNvoKijzJsTOSE0w08wst=zxoTa95Jx8xVfRWmCWJTJ=4g@mail.gmail.com> <CAFifEMLrWwBoPDQZiHvp65zwS+0CEka1sSoLMYQo6ydYit3aNQ@mail.gmail.com> <CAAXAoJUdJP-WUa8sxt_3L+=09wQb_UUOGq0517ibzYrVoU8aOA@mail.gmail.com> <CAFifEMLvsHA9eOZS6MRNCvVa_c+jEOoPsmXbMrbC09aY=0-MZQ@mail.gmail.com>
In-Reply-To: <CAFifEMLvsHA9eOZS6MRNCvVa_c+jEOoPsmXbMrbC09aY=0-MZQ@mail.gmail.com>
From: Jack Firth <jackhfirth@gmail.com>
Date: Thu, 01 Aug 2019 00:07:14 -0700
Message-ID: <CAAXAoJUvdPaFU-xjaVTC8J9=bLe6QfyEnsyHLM1EMUKN1HNtTg@mail.gmail.com>
To: Bin Ni <nibin@quantil.com>
Cc: Chris Lemmons <alficles@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="000000000000dacf43058f08e4c1"
Received-SPF: pass client-ip=2607:f8b0:4864:20::72b; envelope-from=jackhfirth@gmail.com; helo=mail-qk1-x72b.google.com
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1ht5Bi-0000rS-U7 51fa5bef71e3f9edafe61593bc292f7a
X-caa-id: 34ccab1ec0
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Redirection to Other IP Addresses
Archived-At: <https://www.w3.org/mid/CAAXAoJUvdPaFU-xjaVTC8J9=bLe6QfyEnsyHLM1EMUKN1HNtTg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36909
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Yes you could make a status code, but I don't follow why you need a new status code instead of reusing a generic 300 response with body explaining they need to follow Alt-Svc. A special status code requires clients to implement new behavior, and if they're doing that already can't they just implement Alt-Svc support instead? As for 4xx, it sounds like a client error to me in the same way that 429 Too Many Requests is: the client asked for something correctly, but did so in a way that places too great a burden on the server. On Thu, Aug 1, 2019 at 12:03 AM Bin Ni <nibin@quantil.com> wrote: > Hi Jack, > > Potentially, we can extend RFC 7838, as I mentioned in my proposal > <https://docs.google.com/document/d/1gtF6Nq3iPe44515BfsU18dAxfCYOvQaekiezK8FEHu0/edit#heading=h.e8fyx0s8f7wy>, > to define the behavior of client and server when "alt-svc" is used in > conjunction with a special status code. This is still a change/extension to > the existing protocol. I feel 4xx is not good for this purpose, since this > is not a client error. I think a 3XX is more appropriate. > > Thanks! > > Bin > > On Wed, Jul 31, 2019 at 10:52 PM Jack Firth <jackhfirth@gmail.com> wrote: > >> Versus with "alt-svc", the server will serve the content for the current >>> request, client will finish receiving the response and MAYBE connect to the >>> new IP for the next request. >> >> >> Could you return a 4xx error with the Alt-Svc header set, and a body >> message that tells clients they must use the Alt-Svc if they don't want to >> get a 4xx? Or even a generic 300? It seems reasonable to me for a CDN >> server to refuse to serve requests it knows will be prohibitively >> expensive, while providing clients with Alt-Svc as a way to find a >> less-expensive alternative. >> >> On Wed, Jul 31, 2019 at 8:55 PM Bin Ni <nibin@quantil.com> wrote: >> >>> Hi Chris, >>> >>> There are a few caveats in your reasoning: >>> 1. It does not have to be some "accept header". It can be the >>> "User-Agent" header as I mentioned, for example, chrome version > 100. Or >>> on contract. For example, some CDN customers have full control of the >>> client software. They just tell the CDN provider that "you can enable the >>> 312 redirection on all of our domains". >>> 2. Even when it does rely on some "accept header", there is still a >>> critical difference from "alt-svc": >>> In this proposal, the current request will not be served. The client >>> will get a 312 and forced to reconnect to the new IP, similar to the 30X >>> redirection. >>> Versus with "alt-svc", the server will serve the content for the >>> current request, client will finish receiving the response and MAYBE >>> connect to the new IP for the next request. >>> >>> Hope this is more clear. Please don't hesitate with more questions! >>> Thanks! >>> >>> Bin >>> >>> On Wed, Jul 31, 2019 at 6:49 PM Chris Lemmons <alficles@gmail.com> >>> wrote: >>> >>>> So, the typical mechanism for that would be an accept header of some >>>> sort. But if clients are opting into the redirect, then the redirect is >>>> effectively optional. Any client that would set the accept header can >>>> instead just support alt-svc today and choose to redirect. >>>> >>>> On Wed, Jul 31, 2019 at 7:39 PM Bin Ni <nibin@quantil.com> wrote: >>>> >>>>> Hi Chris, >>>>> >>>>> Great question! >>>>> The solution is that the server will only return the new status code >>>>> 312 if it is sure the client can support it. >>>>> The information can be from the User-Agent header, or some other >>>>> request header. >>>>> Or communicated through some other channel, for example, on a paper >>>>> contract. >>>>> >>>>> Thanks! >>>>> >>>>> Bin >>>>> >>>>> >>>>> On Wed, Jul 31, 2019 at 2:36 PM Chris Lemmons <alficles@gmail.com> >>>>> wrote: >>>>> >>>>>> So I have to wonder about the end usefulness from an implementation >>>>>> perspective. Part of why alt-svc works is that it's optional, so >>>>>> servers can use them as optimization but everything else still works. >>>>>> >>>>>> If you have a new protocol that means basically "alt-svc, but >>>>>> mandatory", it means the CDN, load balancer, or similar service simply >>>>>> wouldn't work for any client that didn't understand the new value. >>>>>> There are a _lot_ of http clients out there. This would be a fairly >>>>>> high barrier to adoption, which would create a chicken-and-egg problem >>>>>> that would be tough to solve. >>>>>> >>>>>> On Tue, Jul 30, 2019 at 5:53 PM Bin Ni <nibin@quantil.com> wrote: >>>>>> > >>>>>> > Hi Amos and All, >>>>>> > >>>>>> > Regarding the 30X redirect across different cache servers, it is >>>>>> already used by many big CDN companies that I know of. >>>>>> > It is proven to make the system faster without much burden on the >>>>>> front-end layer which you are concerned. >>>>>> > But 30X has the limitations I mentioned. This is why I'm proposing >>>>>> this new type of redirection to address the limitations. >>>>>> > >>>>>> https://docs.google.com/document/d/1gtF6Nq3iPe44515BfsU18dAxfCYOvQaekiezK8FEHu0/edit?usp=sharing >>>>>> > So it is not a question that this proposal will be useful or not. >>>>>> > I know it will at least be very useful to those CDNs. >>>>>> > >>>>>> > Thanks for your comments. >>>>>> > Please let me know if you have any questions. >>>>>> > >>>>>> > Bin >>>>>> > >>>>>> > On Tue, Jul 30, 2019 at 12:38 AM Amos Jeffries < >>>>>> squid3@treenet.co.nz> wrote: >>>>>> >> >>>>>> >> On 30/07/19 7:02 am, Bin Ni wrote: >>>>>> >> > Yes, what we want is a way to force a "deterministic behavior >>>>>> from the >>>>>> >> > client", just like all the 30X redirections today. >>>>>> >> > >>>>>> >> > Let me give a few more cases in which this can be helpful: >>>>>> >> > 1. A client in North America is returned a server IP in Europe >>>>>> by the >>>>>> >> > DNS. The server then wants to direct the client to another >>>>>> server in >>>>>> >> > North America for better performance. >>>>>> >> > 2. The content of a website is hashed to multiple servers based >>>>>> on URL. >>>>>> >> > These multiple servers may not even be in the same datacenter. >>>>>> The DNS >>>>>> >> > does not have this information and may return any IP to any >>>>>> query of the >>>>>> >> > website's hostname. Each server will calculate the hash for each >>>>>> >> > request and redirect client to the correct server that has the >>>>>> content. >>>>>> >> > This is quite common for CDN. >>>>>> >> >>>>>> >> It is common for good reason: efficiency. >>>>>> >> >>>>>> >> There is a secondary level of efficiency that comes from the >>>>>> redirects >>>>>> >> being actual HTTP 30x redirects. Having large objects at different >>>>>> URL >>>>>> >> entirely provides for a different CDN or caching layer closer to >>>>>> the >>>>>> >> client to provide the large object contents. DNS can be (often is) >>>>>> >> involved in that layer to provide the closest server IP. >>>>>> >> >>>>>> >> As proposed so far your mechanism would flatten this two-tier >>>>>> structure. >>>>>> >> Forcing the frontend layer (now only layer) to be involved in >>>>>> deciding >>>>>> >> the specific hardware location of individual objects / resources. >>>>>> >> Making the frontend machinery store more information and do more >>>>>> work >>>>>> >> per-request is not going to make the system faster, quite the >>>>>> opposite. >>>>>> >> >>>>>> >> >>>>>> >> By separating the work into the three layers: frontend LB, cache, >>>>>> and >>>>>> >> origin. Each CDN layer gets some orders of magnitude increase in >>>>>> >> performance / capacity: >>>>>> >> - origin able to handle/generate some few thousand responses per >>>>>> second, >>>>>> >> - cache able to re-distribute those as static objects at line >>>>>> speed for >>>>>> >> an order or two magnitude more than origins, >>>>>> >> - frontend LB able to handle millions of the small ~1KB >>>>>> >> request/response pairs for redirection spreading that high load >>>>>> across >>>>>> >> the lower layers. >>>>>> >> >>>>>> >> >>>>>> >> AYJ >>>>>> >> >>>>>> > >>>>>> >>>>> >>>>> > > -- > > Bin Ni > VP of Engineering > [image: Quantil] > > Connecting users with content...it's that simple. > > Office: +1-888-847-9851 <(888)%20847-9851> > > [image: Tweeter] <https://twitter.com/Team_Quantil> [image: Google Plus] > <https://plus.google.com/+Quantil_team/> [image: Linked In] > <https://www.linkedin.com/company/quantil> > > The information contained in this email may be confidential and/or legally > privileged. It has been sent for the sole use of the intended recipient(s). > If the reader of this message is not an intended recipient, you are hereby > notified that any unauthorized review, use, disclosure, dissemination, > distribution, or copying of this communication, or any of its contents, is > strictly prohibited. If you have received this communication in error, > please reply to the sender and destroy all copies of the message. To > contact us directly, send to QUANTIL, INC. at 1919 S Bascom Ave #600, > Campbell, CA 95008 > <https://maps.google.com/?q=1919+S+Bascom+Ave+%23600,+Campbell,+CA+95008&entry=gmail&source=g>, > or visit our website at www.quantil.com. <https://www.quantil.com/> > >
- Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Julian Reschke
- Re: Redirection to Other IP Addresses Ryan Hamilton
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Julian Reschke
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Julian Reschke
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Oliver, Wesley, Vodacom South Africa (External)
- Re: Redirection to Other IP Addresses Ben Schwartz
- Re: Redirection to Other IP Addresses Kyle Rose
- Re: Redirection to Other IP Addresses Bin Ni
- RE: Redirection to Other IP Addresses Mike Bishop
- Re: Redirection to Other IP Addresses Wesley Oliver
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Amos Jeffries
- Re: Redirection to Other IP Addresses Oliver, Wesley, Vodacom South Africa (External)
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Chris Lemmons
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Chris Lemmons
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Jack Firth
- Re: Redirection to Other IP Addresses Jack Firth
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Daniel Stenberg
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Martin Thomson
- Re: Redirection to Other IP Addresses Daniel Stenberg
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Martin Thomson
- Re: Redirection to Other IP Addresses Patrick McManus
- Re: Redirection to Other IP Addresses W. Felix Handte
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Erik Nygren
- Re: Redirection to Other IP Addresses Erik Nygren
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Mark Nottingham
- RE: Redirection to Other IP Addresses Mike Bishop
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Erik Nygren
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses craigt
- Re: Redirection to Other IP Addresses Bin Ni
- RE: Redirection to Other IP Addresses Mike Bishop
- Re: Redirection to Other IP Addresses Rob Sayre
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Mark Nottingham
- Re: Redirection to Other IP Addresses Erik Nygren
- Re: Redirection to Other IP Addresses Lucas Pardue