Re: Redirection to Other IP Addresses

Lucas Pardue <lucaspardue.24.7@gmail.com> Thu, 22 August 2019 13:48 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 1400B1200E6 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 22 Aug 2019 06:48:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.75
X-Spam-Level:
X-Spam-Status: No, score=-0.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_VISITOURSITE=2, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=pass (2048-bit key) 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 iri8q2fW48iQ for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 22 Aug 2019 06:48:32 -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 C03A91200EF for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 22 Aug 2019 06:48:31 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1i0nPS-0005VQ-7o for ietf-http-wg-dist@listhub.w3.org; Thu, 22 Aug 2019 13:45:50 +0000
Resent-Date: Thu, 22 Aug 2019 13:45:50 +0000
Resent-Message-Id: <E1i0nPS-0005VQ-7o@frink.w3.org>
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 <lucaspardue.24.7@gmail.com>) id 1i0nPM-0005UU-Nj for ietf-http-wg@listhub.w3.org; Thu, 22 Aug 2019 13:45:44 +0000
Received: from mail-vs1-xe44.google.com ([2607:f8b0:4864:20::e44]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <lucaspardue.24.7@gmail.com>) id 1i0nPI-0001CD-Js for ietf-http-wg@w3.org; Thu, 22 Aug 2019 13:45:44 +0000
Received: by mail-vs1-xe44.google.com with SMTP id b187so3856348vsc.9 for <ietf-http-wg@w3.org>; Thu, 22 Aug 2019 06:45:19 -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=p6dDXXLuJ/cqCoIRmAy1TKCTn0bQWOurtgVJkj/JVCU=; b=dcOp9ffvBB5L3D7qPPN9szrv4AYlUM7hvRAL/xbRjka3Wnmv2BcxGU3oY8aBmnYFqn Bnv8G7b2NjSBC641KMaTposzrlQb7b+/on9myeOekSId7bsAVlqxrcv0yshperzLuilH oGeLW+lwD4eBKGo3/ONXdmAu1oXjNcP6Jvtc+L5nnQh9y4DsX/8VmWGmVm5Z/kLxLSdv 5a+I6aPGGrqbkYbs58LlohYxg+Go7+8m73XZARw6CE11b5TY4cz6Q4GRMU5evjUEYCtu JVG91rXUKkw1PPSnROl+cHLkcoVzjJd/nrSMY8kXptUdUx5WRofR7cZWXhvzLCQezjuI W86A==
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=p6dDXXLuJ/cqCoIRmAy1TKCTn0bQWOurtgVJkj/JVCU=; b=S8HAiJ9MATWec31/fBAJVBbUIhIJVE5cZJsvdBhOPWnqD2KzQskxaGlbt6tOjTI78M ieiKpH9afFKrljGtHN6nP5feso9o6QsAaYXRkgd8Mxm2DpQuS81mRi6fCfBITDvgOaOX CSGiRDjcxnByYu5J7N2o9NAh8J0KupfI8xk3TNX/3x+bBNdmGoGtn7cmYyIB3ObJbgas M8TQoCq759bpbE/BOQU+hW8+WXmi4Z6ZGkQa9E6lpEIcqf/2aYWNufCtBn5a9B4u+I0D Vy8AM6oDcWUPiBPiu33L7NmulebLRHKHA3KFbnVxEy3OJIxj7Q8As1RZfJleKRQjpFXK m7bw==
X-Gm-Message-State: APjAAAWzSY5MHCIMZTc1a4yuMkEszWxzTO7R0B26YTZ4HniO454EHu0z AgmOZLmMxlm7ntH+NvpGUQO0JkUn9v9AjmZOZf+XHNzU
X-Google-Smtp-Source: APXvYqxbCgZ6X1lTP7pyUlM69FGQ5Aao0KMRGITUBWmp7chGVj/4PilVAeBYB2C1J/R5rTjEOANbO0Zxs4BovmZulc8=
X-Received: by 2002:a67:3141:: with SMTP id x62mr24412140vsx.15.1566481519240; Thu, 22 Aug 2019 06:45:19 -0700 (PDT)
MIME-Version: 1.0
References: <CAFifEMLOHp5=OqUXZbg_WKNQmNsTW3Bg5P4btJdX06CF=Wi2AA@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> <CAAXAoJUvdPaFU-xjaVTC8J9=bLe6QfyEnsyHLM1EMUKN1HNtTg@mail.gmail.com> <alpine.DEB.2.20.1908010950240.24744@tvnag.unkk.fr> <CAFifEML6zwvKZJwO0P0L_bvOq8ow1U1j4UkfOTJf0CDRjL71ig@mail.gmail.com> <alpine.DEB.2.20.1908011055320.16907@tvnag.unkk.fr> <CAFifEMLECLpz=E1h7jBPY_5_KSzTRoV-ajc9aMLvEUB8RS68QQ@mail.gmail.com> <0798f7aa-0fac-b7e0-a38d-2b0c781ae50d@felixhandte.com> <CAFifEMKwhxnrjaHiaW-x7oENhhn8XUOZrMZDBL=E1G1WSvPXdg@mail.gmail.com> <CAKC-DJjDS2u5XDGmd4E7dKUvS7aNqKZ3EeCkWKk7OE4q6EpuBw@mail.gmail.com> <CY4PR22MB0983267495973365C74465FFDAAD0@CY4PR22MB0983.namprd22.prod.outlook.com> <CAFifEMKf9RQ7WiKBTTKC8G=0CbzQM6PLyFwn_7=pqQwBoCSSJA@mail.gmail.com> <CAKC-DJiaMU7J4=z6JZ_BR_MF-bbeSAAKwJpHOdvW+mmWUb4_mw@mail.gmail.com> <CAFifEMKMNwYbUMgcUmgHFucVH+GddUm2YXeWagKBf3xzjx2sjg@mail.gmail.com> <CAK-1kekd-BKsY3f3+CukdtxrJOEq5fYky2jMa0ubdr=Mfe14Tg@mail.gmail.com> <EDD06B9A-76E8-48C1-B278-916F54E22934@mnot.net> <CAKC-DJiNhVqgtrpTS06gGseSPree1dDeB=7OeWz-CU44yb2-3w@mail.gmail.com>
In-Reply-To: <CAKC-DJiNhVqgtrpTS06gGseSPree1dDeB=7OeWz-CU44yb2-3w@mail.gmail.com>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Thu, 22 Aug 2019 14:45:07 +0100
Message-ID: <CALGR9oY-v0gjaJ1pEG2YLM+LTH+JHo=S3_37_S2CGs9cMK2WXA@mail.gmail.com>
To: Erik Nygren <erik+ietf@nygren.org>
Cc: Mark Nottingham <mnot@mnot.net>, craigt <c@gryning.com>, Bin Ni <nibin@quantil.com>, Mike Bishop <mbishop@evequefou.be>, "W. Felix Handte" <w@felixhandte.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="0000000000008069160590b4e624"
Received-SPF: pass client-ip=2607:f8b0:4864:20::e44; envelope-from=lucaspardue.24.7@gmail.com; helo=mail-vs1-xe44.google.com
X-W3C-Hub-Spam-Status: No, score=-2.4
X-W3C-Hub-Spam-Report: AWL=1.477, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1i0nPI-0001CD-Js 53a5503b0e9fa5997bb2157c3a5620b6
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Redirection to Other IP Addresses
Archived-At: <https://www.w3.org/mid/CALGR9oY-v0gjaJ1pEG2YLM+LTH+JHo=S3_37_S2CGs9cMK2WXA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36998
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>

Hi Erik,

Thanks for sharing, I wasn't aware of
draft-nygren-httpbis-connection-redirect-00 or some of the background to
Alt-Svc. I think there are some attractive properties to being able to
direct based on path but acknowledge the complexities.

One use case I worked on was to do layer 7 direction of adaptive video
streaming clients to different IPs based on the quality of the video [1].
For example, when a client requests a single video segment at HD quality,
all future requests for that quality should go elsewhere. We built a PoC
based on Alt-Svc and it would have been preferable to keep the DASH URL
pattern that encodes the representation detail in the path. Instead,
because of Alt-Svc's origin-level redirection, we had to map this
information into the host, which has several downsides for larger
deployments. At the time, I penciled out what it might look like to add
path-based pattern matching to Alt-Svc, and I probably came up with a
similar answer to what you describe.

[1] draft-pardue-mcast-quic-05,which specifies how Alt-Svc can be used to
advertise the properties of QUIC packets and HTTP/3 payloads being sent to
multicast IP addresses.




On Thu, Aug 22, 2019 at 1:44 PM Erik Nygren <erik+ietf@nygren.org>; wrote:

> Bin, I'm still not sure if a major part of your use-case is to use
> different Alternative Services for different URLs within the same Origin?
> That seems like an important input requirement differentiating between a
> number of the different options here.  It's also the one that changes the
> semantics of Alt-Svc most dramatically over what they are today.  In
> addition to being optional, Alt-Svc is also scoped to the Origin which
> presumably simplifies both client implementation but also significantly
> simplifies semantics.
>
> For example, if a client is requesting a bunch of URLs in parallel from
> the same origin
> (eg, different large streaming movies), would we want them each to be able
> to go to different places?  That seems like a major use-case not covered by
> the current Alt-Svc.
>
> A precursor to Alt-Svc covered a bunch of these, although the semantics
> were not as fleshed out as they could have been:
> draft-nygren-httpbis-connection-redirect-00
> That both had a way to scope Alt-Svc to a Path as well as an attribute
> indicating that this should be handled immediately:
>
>    2.  The Path specified in the Alt-Server-Policy is a prefix of the
>        request-path for the subsequent request (including the case where
>        they string-compare equal).
>    [...]
>    Depending on the policy-when-value the behavior should change:
>       * "immediate" - the client SHOULD abort this HTTP request and re-
>          issue the request to an alt-server.  This MUST NOT be returned in
>          response to non-idempotent requests (such as POST/PUT).
>       * "next" = the client SHOULD continue with any in-flight HTTP
>          requests but should in-parallel establish a connection to the alt-
>          server for use in subsequent requests.
> The impact on client complexity was a big reason these were abandoned in Alt-Svc.
>
> To Mark's point, Alt-Svc also hasn't gotten critical mass of good client implementations yet, even so.
> Handling clients not supporting this was also a challenge (ie, even with the "immediate" label
> as a hint it was less clear what to do about the content itself, such as whether to return it,
> do a 100 response, or pause some for clients to disconnect).
>
> Extrapolating on Mike's OOB encoding suggestion, what about allowing
> the Alternative-Service to be provided as a hint along with the OOB response and scoped to that particular OOB-encoded URL?
>
> Somewhere back in time or in some mail thread I had a proposal which did this for this purpose.
>
> For example, if the client signaled support through a header and the response was:
>
> HTTP/1.1 200 OK
> Content-Encoding: out-of-band
>
> Vary: Accept-Encoding
>
> {
>     "sr": [
>       { "r" : "/c/bae27c36-fa6a-11e4-ae5d-00059a3c7a00",
>                "alt-svc": [ "h2=\"cdn-node-75.example.net:443\"" ] }
>     ]
> }
>
> Where in this case the alt-svc was scoped purely to the particular OOB-encoded URL response.
> In the case where the origin matches the origin returning the OOB response, cookies can be sent.
>
> All of these do add lots of complexity to client connection pool
> management as connections no longer
> can be keyed purely off of Origin but also need some way to index into
> some Alt-Svc or path or URL property as well.
> The impact on code complexity for connection management (and a need to
> refactor) is a major reason why
> one major client never added Alt-Svc support.  Even more complexity here
> might make it less likely?
>
> Overall this is a direction that I suspect that a number of server-side / CDN providers would be quite interested in.
> What would it take to get general-purpose client software interested?  Are any here interested? Without them it is an academic exercise.
>
> Another reason to combine with OOB-encoding is that there are enough other things that can be done with it (especially in cases
> where cookies are NOT send and where the server CDN serving the content is not trusted to see cookies or even the content itself)
> to make clients potentially more interested.
>
>        Erik
>
>
>
> On Thu, Aug 22, 2019 at 12:18 AM Mark Nottingham <mnot@mnot.net>; wrote:
>
>> My .02 -
>>
>> Any new protocol element along these lines needs to be optional, to make
>> it backwards-compatible with existing clients.
>>
>> Introducing a new status code here is application-visible, when you
>> really want behaviour that is hidden. That's one of the big advantages of
>> Alt-Svc, I think.
>>
>> So, a flag on Alt-Svc that basically says "I really want you to use this
>> alt-svc for any new requests, even if you have to wait for that connection
>> to spin up" would help.
>>
>> What you'd also need is a way to convey that information to the client
>> for *this* response (since the Alt-Svc header only affects requests after
>> the response it occurs upon).
>>
>> 421 Misdirected request would do that, but it means that clients that
>> don't support 421 or Alt-Svc with a different hostname won't be able to get
>> anything for that URL (see above: re optional).
>>
>> Modifying the semantics of the new Alt-Svc flag to "I really want you to
>> use this alt-svc for *this* response and any new requests, even if you have
>> to wait for that connection to spin up" might do it.
>>
>> A 1xx response that contains the Alt-Svc + new flag, followed by a short
>> pause is kind of interesting here; it gives the client the opportunity to
>> sever the connection without wasting (much) bandwidth.
>>
>> Or you could just put the Alt-Svc + new flag onto the normal response,
>> and pace the start of the response a bit (for ~1RT) to a similar effect.
>>
>> The biggest barrier to adoption here by far is getting clients to adopt
>> something; Alt-Svc was specified some time ago now, and is still not
>> available cross-host in Chrome. The other thing to look at is how much
>> surface area you're adding -- and therefore, how much security analysis is
>> necessary. Reusing Alt-Svc seems like a good start there.
>>
>> Cheers,
>>
>>
>> > On 15 Aug 2019, at 10:59 pm, craigt <c@gryning.com>; wrote:
>> >
>> > Just catching up on this thread:
>> >
>> > Bin, It's great to hear of others wanting a solution in this area....
>> >
>> > I set up a proof of concept for something very similar to this using
>> > Alt-Svc, and it worked really well (on Firefox). The preferred path
>> > was almost always set up before the bulk download was initiated due to
>> > companion assets. The problem was that most user agents only
>> > implemented protocol upgrade via Alt-Svc rather than 'connection
>> > migration' or almost in this case 'http traffic engineering'.
>> > Alt-Svc also has other useful properties when used in conjunction with
>> > single address endpoints like failback to origin and multiple
>> > alternates.
>> >
>> > The use case described here, which was very similar to my own at the
>> > time, has a 'lowest common capability' issue so the OPTIONAL aspects
>> > of Alt-Svc make it unusable without support from the bulk of clients.
>> > However, given Alt-Svc has become near essential for protocol upgrade
>> > and partially supported by all, how can we encourage client
>> > implementors to work towards:
>> >
>> > "Therefore, if a client supporting this specification becomes aware of
>> >   an alternative service, the client SHOULD use that alternative
>> >   service for all requests to the associated origin as soon as it is
>> >   available"
>> >
>> > Or a method of signalling that Alt-Svc/equivalent is not optional in
>> $case....
>> >
>> >
>> > On Wed, 14 Aug 2019 at 23:53, Bin Ni <nibin@quantil.com>; wrote:
>> >>
>> >> Hi Erik and All,
>> >>
>> >> My use case is we have a bunch of reverse proxy servers all over the
>> world (just like any other CDN providers).
>> >> Our customers deploy proxy policies to all those servers.
>> >> Assume company ABC is one of our customers, they may configure all our
>> servers to serve https://download.abc.com, with the certificate for
>> "download..abc.com" installed on each of the servers.
>> >> They also configure their DNS to point www.abc.com to a CNAME
>> provided by us, such that my company essentially takes over the resolution
>> of that hostname.
>> >> When an end-user is visiting download.abc.com, the hostname is
>> resolved by our DNS server to one of the server's IP addresses.
>> >> This IP address is chosen based on some algorithm. But this algorithm
>> has some limitations which may not always return an IP that is optimal for
>> the end user.
>> >> When the end user reaches that IP to download some object, for example
>> https://download.abc.com/movie.mp4 (potentially with some cookie
>> targeting "download.abc.com"), an algorithm running on that server
>> >> finds out that another server would provide better performance and
>> want to redirect the end user to the new server to download the object.
>> >> Right now what we can do is sending 30X redirection to the end user
>> with something like:
>> >> Location: https://{new IP}.mycompany.com/download.abc.com/movie.mp4
>> >> As I mentioned in earlier posts, this current method breaks cookie and
>> company ABC's client (maybe a mobile App) may refuse to be directed to a
>> different domain.
>> >>
>> >> Hope this is a clear enough description of the use case. Please let me
>> know of any questions.
>> >> Thanks!
>> >>
>> >> Bin
>> >>
>> >> On Wed, Aug 14, 2019 at 1:11 PM Erik Nygren <erik+ietf@nygren.org>;
>> wrote:
>> >>>
>> >>> You get something in the middle ground.  The Origin doesn't change,
>> but cookies don't get sent without extra work.
>> >>> But you gain the ability to decouple the server certificate and trust
>> and integrity from the Origin.
>> >>> They do solve slightly different but heavily overlapping problems.
>> >>>
>> >>> It may make sense to take a step back and enumerate the set of
>> problems and use-cases
>> >>> that would be good to solve and see which ones there is interest in
>> addressing, and then
>> >>> finding a solution that covers this set.
>> >>>
>> >>> In order for any effort on this front to be worthwhile it will also
>> require
>> >>> getting interest and buy-in to collaborate and implement from both
>> server
>> >>> operators and client implementations, with the client implementations
>> >>> being the one that is going to be especially critical to success.
>> >>> (Even Alt-Svc has had limited client implementation to-date.)
>> >>>
>> >>>     Erik
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Wed, Aug 14, 2019 at 3:38 PM Bin Ni <nibin@quantil.com>; wrote:
>> >>>>
>> >>>> Hi Mike and Eric,
>> >>>>
>> >>>> If looks to me that if I use oob encoding for my use case, it will
>> be the same as 30X redirection.
>> >>>> I won't be able to achieve my goal of "only change the IP address,
>> everything else remain the same".
>> >>>>
>> >>>> Bin
>> >>>>
>> >>>>
>> >>>> On Wed, Aug 14, 2019 at 7:34 AM Mike Bishop <mbishop@evequefou.be>;
>> wrote:
>> >>>>>
>> >>>>> I second this – given that you’re looking for a forced redirect, an
>> out-of-band response coupled with an Alt-Svc to the other host should
>> provide the right behavior.  The first request goes OOB and the client gets
>> the payload from the alternate; the subsequent requests can be made
>> directly to the alternative, since it also has a cert for the origin.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> From: Erik Nygren <erik+ietf@nygren.org>;
>> >>>>> Sent: Thursday, August 8, 2019 9:27 PM
>> >>>>> To: Bin Ni <nibin@quantil.com>;
>> >>>>> Cc: W. Felix Handte <w@felixhandte.com>;; HTTP Working Group <
>> ietf-http-wg@w3.org>;
>> >>>>> Subject: Re: Redirection to Other IP Addresses
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> Another directional approach for this use-case would be out-of-band
>> content encoding.
>> >>>>>
>> >>>>> For example:
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> https://tools.ietf.org/id/draft-reschke-http-oob-encoding-12.html
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> It is possible that this could cover at least some of the use-cases.
>> >>>>>
>> >>>>> It has the benefit that the client signals support (via
>> Accept-Encoding).
>> >>>>>
>> >>>>> The target won't get cookies, but authenticators could be passed in
>> the URL target.
>> >>>>>
>> >>>>> It also has some better properties for not having to fully trust
>> the redirect target
>> >>>>>
>> >>>>> and not having to have the same cert on the redirect target.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>    Erik
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> On Thu, Aug 1, 2019 at 2:58 PM Bin Ni <nibin@quantil.com>; wrote:
>> >>>>>
>> >>>>> Hi Felix,
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> What you described is exactly what my company (you probably already
>> figured out that I work for a CDN company)
>> >>>>>
>> >>>>> is providing to our customers today. The problems are:
>> >>>>>
>> >>>>> 1. In your example, the first host "cdn.com" is the CDN customer's
>> hostname. They usually can't provide us with a "*.geo.cdn.com" wildcard
>> cert. Some of them requires EV certificate, which does not even support
>> wildcard.
>> >>>>>
>> >>>>> 2. Cookies are often targeting a specific hostname. We can't ask
>> all our customer to change the business logic of their web application to
>> make sure all cookies are targeting the entire domain.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> Hope this helps. Any more questions?
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> Bin
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> On Thu, Aug 1, 2019 at 9:37 AM W. Felix Handte <w@felixhandte.com>;
>> wrote:
>> >>>>>
>> >>>>> Bin,
>> >>>>>
>> >>>>> I've been following along on this discussion and it's still not
>> clear to
>> >>>>> me why 30X doesn't solve this use case. Take for example a request
>> and
>> >>>>> response as follows.
>> >>>>>
>> >>>>>   GET /large_file HTTP/1.1
>> >>>>>   Host: cdn.com
>> >>>>>
>> >>>>> To which the server responds with
>> >>>>>
>> >>>>>   HTTP/1.1 307
>> >>>>>   Location: https://singapore.geo.cdn.com/large_file
>> >>>>>
>> >>>>> Or even
>> >>>>>
>> >>>>>   HTTP/1.1 307
>> >>>>>   Location: https://123_45_67_89.ip.cdn.com/large_file
>> >>>>>
>> >>>>> Maybe I'm missing something, but as I understand it, HTTPS and
>> Cookies
>> >>>>> should work with the above (assuming you have wildcard certs for
>> >>>>> *.geo.cdn.com and/or *.ip.cdn.com, and have set your cookies with
>> >>>>> domain=.cdn.com). And it otherwise seems to accomplish exactly
>> your intent.
>> >>>>>
>> >>>>> Can you explain in a little more detail why you believe something
>> along
>> >>>>> those lines wouldn't solve your need?
>> >>>>>
>> >>>>> Thanks,
>> >>>>> Felix
>> >>>>>
>> >>>>> On 8/1/19 6:12 AM, Bin Ni wrote:
>> >>>>>> Hi Daniel,
>> >>>>>>
>> >>>>>> At high level, my proposal is in every other way the same as
>> today's 30X
>> >>>>>> redirection.
>> >>>>>> With this in mind, the answer to your questions are:
>> >>>>>> 1. In general, the alternate IP should only be used once for the
>> next
>> >>>>>> single request.
>> >>>>>> But there is nothing to prevent the clients from remembering it,
>> which
>> >>>>>> is OK.
>> >>>>>> Just like there is nothing to prevent a client to disregard the
>> DNS TTL.
>> >>>>>> They do it with their own risk.
>> >>>>>> 2. This proposal is to fix some limitations of the 30X with
>> Location header.
>> >>>>>> Not very helpful to make it work together with the Location header.
>> >>>>>> 3. We are not requiring every server and every client to support
>> this
>> >>>>>> proposal.
>> >>>>>> For the ones who find it to be useful, the "extra burden" is a
>> non-issue.
>> >>>>>>
>> >>>>>> Thanks!
>> >>>>>>
>> >>>>>> Bin
>> >>>>>>
>> >>>>>> On Thu, Aug 1, 2019 at 2:18 AM Daniel Stenberg <daniel@haxx.se
>> >>>>>> <mailto:daniel@haxx.se>> wrote:
>> >>>>>>
>> >>>>>>    On Thu, 1 Aug 2019, Bin Ni wrote:
>> >>>>>>
>> >>>>>>> 2. my proposed behavior:
>> >>>>>>> Client: Hi Server-1.1.1.1, can you send me the movie XXX?
>> >>>>>>> Server-1.1.1.1: Sorry, I can't give you the movie, you need to
>> >>>>>>    ask server
>> >>>>>>> 2.2.2.2 for this movie.
>> >>>>>>> Client: Hi Server-2.2.2.2, can you send me the movie XXX?
>> >>>>>>> Server-2.2.2.2: Here is the movie.
>> >>>>>>> (It then took 0.5 hours to deliver the movie, because
>> >>>>>>    server-2.2.2.2 is
>> >>>>>>> closer to the client, or less loaded)
>> >>>>>>
>> >>>>>>    If we for a moment play with the idea that we'd do something
>> like
>> >>>>>>    this, then I
>> >>>>>>    think it should be aligned with and work together with Alt-Svc
>> in a
>> >>>>>>    better way
>> >>>>>>    than what is currently proposed...
>> >>>>>>
>> >>>>>>    There's no max-age/TTL. For how long is the user-agent supposed
>> to
>> >>>>>>    consider
>> >>>>>>    the alternative IP addresses as the only ones that the given
>> origin
>> >>>>>>    has?
>> >>>>>>    Forever? Only for the next single connect (attempt)?
>> >>>>>>
>> >>>>>>    Are the alternative IPs supposed to be used for the entire
>> origin or
>> >>>>>>    for that
>> >>>>>>    specific URI only?
>> >>>>>>
>> >>>>>>    A 3xx redirect without a Location: header? Wouldn't it make more
>> >>>>>>    sense and
>> >>>>>>    work more similar to existing 3xx redirects if it also sends a
>> >>>>>>    Location:? Then
>> >>>>>>    existing clients that don't understand 312 might have a higher
>> >>>>>>    chance of at
>> >>>>>>    least doing something sensible.
>> >>>>>>
>> >>>>>>    If a client gets this response and starts downloading huge
>> content
>> >>>>>>    from the
>> >>>>>>    new IP and the client then opens a second connection to the
>> origin
>> >>>>>>    in a second
>> >>>>>>    tab. Which IPs is that supposed to use? The original ones or the
>> >>>>>>    redirected
>> >>>>>>    ones?
>> >>>>>>
>> >>>>>>    Requring user-agent snooping for a server to figure out if the
>> >>>>>>    feature works
>> >>>>>>    or not is a totally broken idea and I think this detail needs
>> to be
>> >>>>>>    worked out
>> >>>>>>    for this idea to be considered for real.
>> >>>>>>
>> >>>>>>    My personal preference is probably to add some sort of "urgency"
>> >>>>>>    thing to
>> >>>>>>    alt-svc instead of this 312 plus several headers, so that a
>> client
>> >>>>>>    can be told
>> >>>>>>    that it should switch sooner rather than later.
>> >>>>>>
>> >>>>>>    --
>> >>>>>>
>> >>>>>>       / daniel.haxx.se <http://daniel.haxx.se>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> --
>> >>>>>>
>> >>>>>> Bin Ni
>> >>>>>> VP of Engineering
>> >>>>>>
>> >>>>>> Quantil
>> >>>>>>
>> >>>>>> Connecting users with content...it's that simple.
>> >>>>>>
>> >>>>>> Office: +1-888-847-9851 <tel:(888)%20847-9851>
>> >>>>>>
>> >>>>>> Tweeter <https://twitter.com/Team_Quantil> Google Plus
>> >>>>>> <https://plus.google.com/+Quantil_team/> 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/
>> >
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>>
>> >>>>> Bin Ni
>> >>>>> VP of Engineering
>> >>>>>
>> >>>>> Connecting users with content...it's that simple.
>> >>>>>
>> >>>>> Office: +1-888-847-9851
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> 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, or visit our website at
>> www.quantil.com.
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>>
>> >>>> Bin Ni
>> >>>> VP of Engineering
>> >>>>
>> >>>> Connecting users with content...it's that simple.
>> >>>>
>> >>>> Office: +1-888-847-9851
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> 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, or visit our website at
>> www.quantil.com.
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >> Bin Ni
>> >> VP of Engineering
>> >>
>> >> Connecting users with content...it's that simple.
>> >>
>> >> Office: +1-888-847-9851
>> >>
>> >>
>> >>
>> >>
>> >> 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, or visit our website at
>> www.quantil.com.
>> >
>> >
>>
>> --
>> Mark Nottingham   https://www.mnot.net/
>>
>>