Resent-Date: Sun, 28 Jul 2024 13:34:51 +0000
Resent-Message-Id: <E1sY431-00D7BE-2L@mab.w3.org>
Received-SPF: pass (puck.w3.org: domain of gmail.com designates 2a00:1450:4864:20::633 as permitted sender) client-ip=2a00:1450:4864:20::633; envelope-from=patmeenan@gmail.com; helo=mail-ej1-x633.google.com;
MIME-Version: 1.0
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>
 <cd25a358-1e8a-43b7-ba61-3d16ad28b1e4@gmx.de> <CAF3KT4Q=ezzA2aCHyPg=k583n6vP4gTGP+wxKz+sQezD=GnowQ@mail.gmail.com>
In-Reply-To: <CAF3KT4Q=ezzA2aCHyPg=k583n6vP4gTGP+wxKz+sQezD=GnowQ@mail.gmail.com>
From: Patrick Meenan <patmeenan@gmail.com>
Date: Sun, 28 Jul 2024 09:34:32 -0400
Message-ID: <CAJV+MGxH4wPK__Z4mGfD3j-KaHpSVjQBFLyM1u+ZwfaSsZGMRQ@mail.gmail.com>
To: Josh Cohen <joshco@gmail.com>
Cc: Julian Reschke <julian.reschke@gmx.de>, ietf-http-wg@w3.org
Content-Type: multipart/alternative; boundary="000000000000ae212e061e4ece97"
Subject: Re: Method Mania
Archived-At: <https://www.w3.org/mid/CAJV+MGxH4wPK__Z4mGfD3j-KaHpSVjQBFLyM1u+ZwfaSsZGMRQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

--000000000000ae212e061e4ece97
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Sorry, I didn't mean to imply not to go forward or to necessarily find a
way to thread the needle but to explicitly plan for there to be
middle-boxes that break and to be deliberate about how to handle that case,
even for HTTPS.

Failing loudly, in obvious and testable ways is WAY better than failing
silently or in random ways. It makes it much easier for IT teams and
software vendors to identify the root cause and test fixes. It can also be
good to force failures broadly rather than pick just a subset of the
population for it to work on (like requiring IPv6 features). There will be
some middleboxes with issues but there will be a lot more that don't have
issues and it would artificially limit the reach of the feature if you
disable it for all middlebox cases.

I expect that new frame types for HTTP/2 and HTTP/3 would be more
compatible than new methods just because devices are already parsing the
existing headers and streams for content and would be more likely to error
out when seeing a method they don't understand (but, odds are, new frames
will have some number of devices that fail as well).

We have seen it more often than I care to admit, with the rollouts for
HTTP/2, brotli, post-quantum TLS and now with compression dictionaries
(which, you'd think the brotli rollout would have prepared devices for
handling content-encoding negotiation in a compatible way, but nope).

The devices tend to fail the connections in painful ways, like closing the
whole connection when it sees payload content it doesn't like (wiping out a
bunch of multiplexed requests on a HTTP/2 connection for example).

Here is the site we're currently sending IT admins to when they get reports
of TLS failures with the post-quantum rollout (mostly because of broken
middleboxes): https://tldr.fail/

I'd encourage the team to continue without trying to get too fancy, just
expect there will be some ecosystem cleanup needed when it is rolled out
and to plan for it.

On Sun, Jul 28, 2024 at 1:33=E2=80=AFAM Josh Cohen <joshco@gmail.com> wrote=
:

> Same here..  Patrick also said:
>>
>> "The better question is under what circumstances do we want to allow
>> those devices to "break" and force them to fix the implementations?"
>
>
> Maybe a reasonable interpretation of Patrick's statement is that it's tim=
e
> to be *bold.  *HTTP/1.1 RFC2616 was published in 1999.  It's the 25 year
> anniversary. =F0=9F=A5=B3  In the intervening years, the IETF has done a =
great job
> evolving the transport.  That's created the foundation for things we
> couldn't do back then.   I don't think it was a coincidence that Lisa
> Dusseault was in the room.  The universe is speaking to us.  Maybe it's
> time for a WebDAV re-spin..  The web could also have standardized pub/sub=
.
>
> If we add new functionality that users and devs want, and makes admin lif=
e
> easier, that could be helpful in driving better implementations, and upta=
ke
> of HTTP/2/3 and masque proxying.
>
>
>
>
>
> On Sat, Jul 27, 2024 at 10:07=E2=80=AFPM Julian Reschke <julian.reschke@g=
mx.de>
> wrote:
>
>> On 27.07.2024 16:44, Patrick Meenan wrote:
>> >
>> >
>> > On Sat, Jul 27, 2024 at 4:23=E2=80=AFAM Julian Reschke <julian.reschke=
@gmx.de
>> > <mailto: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 QUER=
Y
>> >     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 o=
f
>> 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.
>> > ...
>>
>> I meant "safe" wrt deploying new HTTP methods.
>>
>> When was the last time you encountered a problem?
>>
>> Best regards, Julian
>>
>>
>>
>>
>>
>
> --
>
> ---
> *Josh Co*hen
>
>

--000000000000ae212e061e4ece97
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Sorry, I didn&#39;t mean to imply not to go forward or to =
necessarily find a way to thread the needle but to explicitly plan for ther=
e to be middle-boxes that break and to be deliberate about how to handle th=
at case, even for HTTPS.<div><br></div><div>Failing loudly, in obvious and =
testable ways is WAY better than failing silently or in random ways. It mak=
es it much easier for IT teams and software vendors to identify the root ca=
use and test fixes. It can also be good to force failures broadly rather th=
an pick just a subset of the population for it to work on (like requiring I=
Pv6 features). There will be some middleboxes with issues but there will be=
 a lot more that don&#39;t have issues and it would artificially limit the =
reach of the feature if you disable it for all middlebox cases.</div><div><=
br></div><div>I expect that new frame types for HTTP/2 and HTTP/3 would be =
more compatible than new methods just because devices are already parsing t=
he existing headers and streams for content and would be more likely to err=
or out when seeing a method they don&#39;t understand (but, odds are, new f=
rames will have some number of devices that fail as well).</div><div><br></=
div><div>We have seen it more often than I care to admit, with the rollouts=
 for HTTP/2, brotli, post-quantum TLS and now with compression dictionaries=
 (which, you&#39;d think the brotli rollout would have prepared devices for=
 handling content-encoding negotiation in a compatible way, but nope).</div=
><div><br></div><div>The devices tend to fail the connections in painful wa=
ys, like closing the whole connection when it sees payload content it doesn=
&#39;t like (wiping out a bunch of multiplexed requests on a HTTP/2 connect=
ion for example).</div><div><br></div><div>Here is the site we&#39;re curre=
ntly sending IT admins to when they get reports of TLS failures with the po=
st-quantum rollout (mostly because of broken middleboxes):=C2=A0<a href=3D"=
https://tldr.fail/">https://tldr.fail/</a></div><div><br></div><div>I&#39;d=
 encourage the team to continue without trying to get too fancy, just expec=
t there will be some ecosystem cleanup needed when it is rolled out and to =
plan for it.</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cla=
ss=3D"gmail_attr">On Sun, Jul 28, 2024 at 1:33=E2=80=AFAM Josh Cohen &lt;<a=
 href=3D"mailto:joshco@gmail.com">joshco@gmail.com</a>&gt; wrote:<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Same her=
e..=C2=A0 Patrick also said:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">&quot;<span style=3D"font-family:Calibri;font-size:12pt">The
better question is under what circumstances do we want to allow those devic=
es
to &quot;break&quot; and force them to fix the implementations?&quot;</span=
></blockquote><div><br></div><div>Maybe a reasonable interpretation of Patr=
ick&#39;s statement is that it&#39;s time to be=C2=A0<i>bold.=C2=A0=C2=A0</=
i>HTTP/1.1 RFC2616 was published in 1999.=C2=A0 It&#39;s the 25 year annive=
rsary.=C2=A0=F0=9F=A5=B3 =C2=A0In the intervening years, the IETF has done =
a great job evolving the transport.=C2=A0 That&#39;s created the foundation=
 for things we couldn&#39;t do back then.=C2=A0 =C2=A0I don&#39;t think it =
was a coincidence that Lisa Dusseault was in the room.=C2=A0 The universe i=
s speaking to us.=C2=A0 Maybe it&#39;s time for a WebDAV re-spin..=C2=A0 Th=
e web could also have standardized pub/sub.=C2=A0=C2=A0</div><div><br></div=
><div>If we add new functionality that users and devs want, and makes admin=
 life easier, that could be helpful in driving better implementations, and =
uptake of HTTP/2/3 and masque proxying.</div><div><br></div><div><br></div>=
<div><i><br></i></div><div><i><br></i></div></div><br><div class=3D"gmail_q=
uote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Jul 27, 2024 at 10:07=
=E2=80=AFPM Julian Reschke &lt;<a href=3D"mailto:julian.reschke@gmx.de" tar=
get=3D"_blank">julian.reschke@gmx.de</a>&gt; wrote:<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex">On 27.07.2024 16:44, Patrick Meenan wro=
te:<br>
&gt;<br>
&gt;<br>
&gt; On Sat, Jul 27, 2024 at 4:23=E2=80=AFAM Julian Reschke &lt;<a href=3D"=
mailto:julian.reschke@gmx.de" target=3D"_blank">julian.reschke@gmx.de</a><b=
r>
&gt; &lt;mailto:<a href=3D"mailto:julian.reschke@gmx.de" target=3D"_blank">=
julian.reschke@gmx.de</a>&gt;&gt; wrote:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0On 26.07.2024 00:27, Josh Cohen wrote:<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; On the httpwg agenda at IETF 120 were a propo=
sal for a new QUERY<br>
&gt;=C2=A0 =C2=A0 =C2=A0method<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; and Braid, which has subscription functionali=
ty that overloads<br>
&gt;=C2=A0 =C2=A0 =C2=A0the GET<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; method.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; What I am curious about is if, at this point =
in the evolution of the<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; web, it is now safe to add new methods for ne=
w functionality.<br>
&gt;=C2=A0 =C2=A0 =C2=A0I&#39;ve been<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; reading up on HTTP/2/3 and it seems that nowa=
days, connections are<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; end-to-end secure and are essentially tunnele=
d through middle boxes,<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; including HTTP/1.1 proxies. I&#39;m still jus=
t wrapping my head around<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; MASQUE, but it looks like it can handle arbit=
rary methods.=C2=A0 Similarly<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; origin servers have evolved to support arbitr=
ary methods.<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0It always has been &quot;safe&quot;, when https was=
 used.<br>
&gt;<br>
&gt;<br>
&gt; https is not &quot;safe&quot; in practical terms because of middleboxe=
s that<br>
&gt; intercept the connections. It is very common in enterprise deployments=
<br>
&gt; where they install local trust anchors on the client devices and use<b=
r>
&gt; mitm software to inspect the traffic.<br>
&gt; ...<br>
<br>
I meant &quot;safe&quot; wrt deploying new HTTP methods.<br>
<br>
When was the last time you encountered a problem?<br>
<br>
Best regards, Julian<br>
<br>
<br>
<br>
<br>
</blockquote></div><br clear=3D"all"><div><br></div><span class=3D"gmail_si=
gnature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature"><d=
iv dir=3D"ltr"><div><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div=
 dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D=
"ltr"><div dir=3D"ltr"><span></span><div><p><font face=3D"monospace, monosp=
ace">---</font><span style=3D"font-family:monospace,monospace"><br></span><=
b><span style=3D"font-family:Calibri,sans-serif">Josh Co</span></b><span st=
yle=3D"font-family:Calibri,sans-serif">hen=C2=A0</span></p><p style=3D"back=
ground-image:initial;background-position:initial;background-repeat:initial"=
><span style=3D"font-family:Arial,sans-serif"></span></p><p></p></div></div=
></div></div></div></div></div></div></div></div></div></div></div>
</blockquote></div>

--000000000000ae212e061e4ece97--