Resent-Date: Sat, 27 Jul 2024 23:16:50 +0000
Resent-Message-Id: <E1sXqeg-00C9xI-2v@mab.w3.org>
Received-SPF: pass (pan.w3.org: domain of gmail.com designates 2a00:1450:4864:20::132 as permitted sender) client-ip=2a00:1450:4864:20::132; envelope-from=fakedme+http@gmail.com; helo=mail-lf1-x132.google.com;
Sender: "Soni L." <fakedme@gmail.com>
Content-Type: multipart/alternative;
 boundary="------------cczuuCzGy6nRS6ntSeGS6Kwz"
Message-ID: <2c1bfd64-ff88-4f74-a172-3b4e7f039740@gmail.com>
Date: Sat, 27 Jul 2024 20:16:37 -0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Josh Cohen <joshco@gmail.com>
Cc: ietf-http-wg@w3.org
References: <CAF3KT4QZzx+FXOUHZoy+gPqJjQ+4KdOC+_29vbUANNtZQS4c+A@mail.gmail.com>
 <ba56fad8-e121-4c06-9a2d-783ef82471e0@gmx.de>
 <CAJV+MGz8hUTqar51V9wV=WPnWETDK+ECjWCTXYS92xXM5HEF_w@mail.gmail.com>
 <cad0ce47-71fe-4e06-b225-3b11c287a18b@gmail.com>
 <CAF3KT4TF8v9eC979bt9ChWpUpWBOpdvpR0XRfaDcb=aZ6KjTNw@mail.gmail.com>
Content-Language: en-US
From: "Soni L." <fakedme+http@gmail.com>
In-Reply-To: <CAF3KT4TF8v9eC979bt9ChWpUpWBOpdvpR0XRfaDcb=aZ6KjTNw@mail.gmail.com>
Subject: Re: Method Mania
Archived-At: <https://www.w3.org/mid/2c1bfd64-ff88-4f74-a172-3b4e7f039740@gmail.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

This is a multi-part message in MIME format.
--------------cczuuCzGy6nRS6ntSeGS6Kwz
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Indeed.  We believe an IPv6 EH would be a valid solution here, sent at 
connection time.  A middlebox is proxying the HTTP stream around but it 
usually intercepts the TLS/TCP streams, so it would inherently drop the 
relevant methods.  Due to the state of EH support in deployed networks, 
clients should probably send an EH requesting the methods and also do 
Happy Eyeballs without the EH.  Then, if you want the new methods on 
your enterprise network, your only option is to fix your EH support. 
Win-win?

On 2024-07-27 18:40, Josh Cohen wrote:
> I was using "safe" in the narrow scope of methods. Patrick's point may 
> still apply if middle boxes only support pre-defined methods.
>
> To avoid mixing connection semantics, a subscribe request (regardless 
> of http method), could return subscription information that includes 
> how the client receives notifications.
> For example, it could return a websocket address that the client 
> connects to in order to receive a stream of updates. In the case of 
> HTTP/3, a server-client stream could be set up.
> This is how the SUBSCRIBE method in gena/UPNP work.  It just sets up 
> the subscription and notification paths, but doesn't handle the 
> notifications themselves.
>
> If the GET (or any preexisting) method is used, perhaps a content type 
> could be listed in the Accept header such as 
> application/subscription+json.  If the server receives that, it could 
> respond with a braid defines JSON message that contains the relevant 
> notification stream.
>
>
>
> On Sat, Jul 27, 2024 at 8:04 AM Soni L. <fakedme+http@gmail.com 
> <mailto:fakedme%2Bhttp@gmail.com>> wrote:
>
>
>
>     On 2024-07-27 11:44, Patrick Meenan wrote:
>>
>>
>>     On Sat, Jul 27, 2024 at 4:23 AM Julian Reschke
>>     <julian.reschke@gmx.de> wrote:
>>
>>         On 26.07.2024 00:27, Josh Cohen wrote:
>>         > On the httpwg agenda at IETF 120 were a proposal for a new
>>         QUERY method
>>         > and Braid, which has subscription functionality that
>>         overloads the GET
>>         > method.
>>         >
>>         > What I am curious about is if, at this point in the
>>         evolution of the
>>         > web, it is now safe to add new methods for new
>>         functionality. I've been
>>         > reading up on HTTP/2/3 and it seems that nowadays,
>>         connections are
>>         > end-to-end secure and are essentially tunneled through
>>         middle boxes,
>>         > including HTTP/1.1 proxies. I'm still just wrapping my head
>>         around
>>         > MASQUE, but it looks like it can handle arbitrary methods. 
>>         Similarly
>>         > origin servers have evolved to support arbitrary methods.
>>
>>         It always has been "safe", when https was used.
>>
>>
>>     https is not "safe" in practical terms because of middleboxes
>>     that intercept the connections. It is very common in enterprise
>>     deployments where they install local trust anchors on the client
>>     devices and use mitm software to inspect the traffic.
>>
>>     Even HTTP/2 is not necessarily "safe" as we are seeing with the
>>     deployment of compression dictionaries as there are enterprise
>>     mitm devices that inspect HTTP/2 traffic as well (and in our
>>     case, reset connections when they see a content-encoding they
>>     don't understand).
>>
>>     The better question is under what circumstances do we want to
>>     allow those devices to "break" and force them to fix the
>>     implementations? HTTP/S (or just H/2/3 if you want to be less
>>     intrusive) could be considered reasonable because the proxies are
>>     under the control of the site (CDN) or environment where they are
>>     being run (enterprise) and there's not random gear spread
>>     elsewhere in the Internet that needs to be tracked down.  The
>>     site-level is generally easy (don't use the new features on a
>>     given site if the serving path doesn't support it) but cleaning
>>     up the enterprise ecosystem can be a nightmare and a much bigger
>>     case of whack-a-mole.
>>
>>     The alternative (that Chrome uses for HTTP/3) is to only use the
>>     new feature when the connection is TLS-anchored to a well-known
>>     trust root (no middleboxes on the client end) but that is
>>     allowing some portion of the Internet to continue to operate
>>     "broken" infrastructure.
>     Maybe use an IPv6 EH for non-well-known trust roots to claim
>     support? :)
>
>     (only half-joking, but it might help improve EH support.)
>
>
>
> -- 
>
> ---
> *Josh Co*hen
>

--------------cczuuCzGy6nRS6ntSeGS6Kwz
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <font face="monospace">Indeed.  We believe an IPv6 EH would be a
      valid solution here, sent at connection time.  A middlebox is
      proxying the HTTP stream around but it usually intercepts the
      TLS/TCP streams, so it would inherently drop the relevant
      methods.  Due to the state of EH support in deployed networks,
      clients should probably send an EH requesting the methods and also
      do Happy Eyeballs without the EH.  Then, if you want the new
      methods on your enterprise network, your only option is to fix
      your EH support. Win-win?<br>
    </font><br>
    <div class="moz-cite-prefix">On 2024-07-27 18:40, Josh Cohen wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAF3KT4TF8v9eC979bt9ChWpUpWBOpdvpR0XRfaDcb=aZ6KjTNw@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">I was using "safe" in the narrow scope of methods. 
        Patrick's point may still apply if middle boxes only support
        pre-defined methods.
        <div><br>
          <div>To avoid mixing connection semantics, a subscribe request
            (regardless of http method), could return subscription
            information that includes how the client receives
            notifications.</div>
          <div>For example, it could return a websocket address that the
            client connects to in order to receive a stream of updates.
            In the case of HTTP/3, a server-client stream could be set
            up.</div>
          <div>This is how the SUBSCRIBE method in gena/UPNP work.  It
            just sets up the subscription and notification paths, but
            doesn't handle the notifications themselves.</div>
          <div><br>
          </div>
          <div>If the GET (or any preexisting) method is used, perhaps a
            content type could be listed in the Accept header such as
            application/subscription+json.  If the server receives that,
            it could respond with a braid defines JSON message that
            contains the relevant notification stream.</div>
          <div><br>
          </div>
          <div><br>
          </div>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Sat, Jul 27, 2024 at
          8:04 AM Soni L. &lt;<a href="mailto:fakedme%2Bhttp@gmail.com"
            moz-do-not-send="true">fakedme+http@gmail.com</a>&gt; wrote:<br>
        </div>
        <blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
          <div> <br>
            <br>
            <div>On 2024-07-27 11:44, Patrick Meenan wrote:<br>
            </div>
            <blockquote type="cite">
              <div dir="ltr">
                <div dir="ltr"><br>
                </div>
                <br>
                <div class="gmail_quote">
                  <div dir="ltr" class="gmail_attr">On Sat, Jul 27, 2024
                    at 4:23 AM Julian Reschke &lt;<a
                      href="mailto:julian.reschke@gmx.de"
                      target="_blank" moz-do-not-send="true"
                      class="moz-txt-link-freetext">julian.reschke@gmx.de</a>&gt;
                    wrote:<br>
                  </div>
                  <blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On
                    26.07.2024 00:27, Josh Cohen wrote:<br>
                    &gt; On the httpwg agenda at IETF 120 were a
                    proposal for a new QUERY method<br>
                    &gt; and Braid, which has subscription functionality
                    that overloads the GET<br>
                    &gt; method.<br>
                    &gt;<br>
                    &gt; What I am curious about is if, at this point in
                    the evolution of the<br>
                    &gt; web, it is now safe to add new methods for new
                    functionality. I've been<br>
                    &gt; reading up on HTTP/2/3 and it seems that
                    nowadays, connections are<br>
                    &gt; end-to-end secure and are essentially tunneled
                    through middle boxes,<br>
                    &gt; including HTTP/1.1 proxies. I'm still just
                    wrapping my head around<br>
                    &gt; MASQUE, but it looks like it can handle
                    arbitrary methods.  Similarly<br>
                    &gt; origin servers have evolved to support
                    arbitrary methods.<br>
                    <br>
                    It always has been "safe", when https was used.</blockquote>
                  <div><br>
                  </div>
                  <div>https is not "safe" in practical terms because of
                    middleboxes that intercept the connections. It is
                    very common in enterprise deployments where they
                    install local trust anchors on the client devices
                    and use mitm software to inspect the traffic.</div>
                  <div><br>
                  </div>
                  <div>Even HTTP/2 is not necessarily "safe" as we are
                    seeing with the deployment of compression
                    dictionaries as there are enterprise mitm devices
                    that inspect HTTP/2 traffic as well (and in our
                    case, reset connections when they see a
                    content-encoding they don't understand).</div>
                  <div><br>
                  </div>
                  <div>The better question is under what circumstances
                    do we want to allow those devices to "break" and
                    force them to fix the implementations? HTTP/S (or
                    just H/2/3 if you want to be less intrusive) could
                    be considered reasonable because the proxies are
                    under the control of the site (CDN) or environment
                    where they are being run (enterprise) and there's
                    not random gear spread elsewhere in the Internet
                    that needs to be tracked down.  The site-level is
                    generally easy (don't use the new features on a
                    given site if the serving path doesn't support it)
                    but cleaning up the enterprise ecosystem can be a
                    nightmare and a much bigger case of whack-a-mole.</div>
                  <div><br>
                  </div>
                  <div>The alternative (that Chrome uses for HTTP/3) is
                    to only use the new feature when the connection is
                    TLS-anchored to a well-known trust root (no
                    middleboxes on the client end) but that is allowing
                    some portion of the Internet to continue to operate
                    "broken" infrastructure.</div>
                </div>
              </div>
            </blockquote>
            Maybe use an IPv6 EH for non-well-known trust roots to claim
            support? :)<br>
            <br>
            (only half-joking, but it might help improve EH support.)<br>
          </div>
        </blockquote>
      </div>
      <br clear="all">
      <div><br>
      </div>
      <span class="gmail_signature_prefix">-- </span><br>
      <div dir="ltr" class="gmail_signature">
        <div dir="ltr">
          <div>
            <div dir="ltr">
              <div dir="ltr">
                <div dir="ltr">
                  <div dir="ltr">
                    <div dir="ltr">
                      <div dir="ltr">
                        <div dir="ltr">
                          <div dir="ltr">
                            <div dir="ltr"><span></span>
                              <div>
                                <p><font face="monospace, monospace">---</font><span
style="font-family:monospace,monospace"><br>
                                  </span><b><span
style="font-family:Calibri,sans-serif">Josh Co</span></b><span
style="font-family:Calibri,sans-serif">hen </span></p>
                                <p
style="background-image:initial;background-position:initial;background-repeat:initial"><span
                                    style="font-family:Arial,sans-serif"></span></p>
                              </div>
                            </div>
                          </div>
                        </div>
                      </div>
                    </div>
                  </div>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>

--------------cczuuCzGy6nRS6ntSeGS6Kwz--