Received: by ietfa.amsl.com (Postfix) id E3FD3C14CEFC; Thu, 1 Aug 2024 07:12:35 -0700 (PDT) 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 E2FFBC14F71C for ; Thu, 1 Aug 2024 07:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.856 X-Spam-Level: X-Spam-Status: No, score=-2.856 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=w3.org header.b="TQFntcRh"; dkim=pass (2048-bit key) header.d=w3.org header.b="PgHgAst6"; dkim=pass (2048-bit key) header.d=gmail.com header.b="emGydr8H" Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIlf7L14P8Xz for ; Thu, 1 Aug 2024 07:12:32 -0700 (PDT) Received: from mab.w3.org (mab.w3.org [IPv6:2600:1f18:7d7a:2700:d091:4b25:8566:8113]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF37FC14F61A for ; Thu, 1 Aug 2024 07:12:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Subject:Content-Type:Cc:To:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To; bh=Uk69yD0LzK/wEYKqud2wiYSRNmNiBwzwbSZJew0nArU=; b=TQFntcRh9azpSrJ8TgEEvoqsQ/ e12BxRD1bFQspr7LU9Idr0BiJIVTbEhdPMi9M5AnmLNIYs0WerCqzNdBAmKqO5TV38JQrPaOqjT7l C8VShoaFY4ixlFN10rF9xLfcXtRHdgTkP53fu6uZ/YXXzLUS3w9WHmtfhnGh6mwzEBj2SQEp8l0st kODWKkpieqTc54QYSw6acPZGl91YjqaY30F1ctQBu94Ve2odZqRHgOi9uzryja5aKUxvlBerlOcwT 9lt4FjuczAfHxOsIjPOXEE1nHBVp06xc8ZyXmH3eioxleuUUUdDVBsCQny1buNDXIsm5SM8qKstqK 1x5j0AZA==; Received: from lists by mab.w3.org with local (Exim 4.96) (envelope-from ) id 1sZWWj-008SFr-2W for ietf-http-wg-dist@listhub.w3.org; Thu, 01 Aug 2024 14:11:33 +0000 Resent-Date: Thu, 01 Aug 2024 14:11:33 +0000 Resent-Message-Id: Received: from ip-10-0-0-224.ec2.internal ([10.0.0.224] helo=puck.w3.org) by mab.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1sZWWh-008SEs-1E for ietf-http-wg@listhub.w3.internal; Thu, 01 Aug 2024 14:11:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To; bh=Uk69yD0LzK/wEYKqud2wiYSRNmNiBwzwbSZJew0nArU=; t=1722521491; x=1723385491; b=PgHgAst6iwflnc4RIcv00S9XJegYw3bNSordfWSY5pZ0cNrJqFhMCoiiMW+FE3/DpLf6/9GWSZx HjzHdA0lkDAKC1zh9FxsvNO8dw4scUd+zMvexZjZtaSVdv3GnFeXsNx91IsuHO0icsclmn0RTAIZJ c/cQBWtU4f16eAL2GlglEwdalB1wqhNi3NMdEba1s8y9UAdv1M7W8JQd6C5rHGR8z58K4QhIyTVSf 60KpBIuWQDVYLinENBiAabjR4Z2T0pMuY9XFcbrQ+yBQteTnWmt6RTo7Uae/hAKrUlQBYJaf925rn xXyBDXlXi7KguaK568OSXA2fdx5Gjb3XjX+A==; Received-SPF: pass (puck.w3.org: domain of gmail.com designates 2001:4860:4864:20::2c as permitted sender) client-ip=2001:4860:4864:20::2c; envelope-from=joshco@gmail.com; helo=mail-oa1-x2c.google.com; Received: from mail-oa1-x2c.google.com ([2001:4860:4864:20::2c]) by puck.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1sZWWg-006xEh-20 for ietf-http-wg@w3.org; Thu, 01 Aug 2024 14:11:31 +0000 Received: by mail-oa1-x2c.google.com with SMTP id 586e51a60fabf-2642cfb2f6aso4588887fac.2 for ; Thu, 01 Aug 2024 07:11:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722521487; x=1723126287; darn=w3.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Uk69yD0LzK/wEYKqud2wiYSRNmNiBwzwbSZJew0nArU=; b=emGydr8HbQeBdsgQAo6W8H2Eu9S6oCQUzjY7/ueTu9deE9LwQwIyxtchNkOawLDrBu UGXbzvy/7HHKtXjXOA/9NIO8akjEYFtRBqKrAg8aXjTQxQTtn3FeFt4o8PyTM7Wd+G6E 5CXAKMyIeieuFyj/VCZRLY3A3e1vEKTFHzXMeWa+lcf4qp/atQUavxWkJ2deOE+TizP5 18qDVA7jcIW1Uu2/3SqDiMQvtlBlxVcRaQ1mtqQtdAWVPz+sP/OEzrHeGykR3TlH+5Bx SrnatYz1NllwOU0HIeoRFQqpgfM7mw6+1wQixQTdIsVjNa6qpyCgFvfu+Prg1fmfutGf UhCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722521487; x=1723126287; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Uk69yD0LzK/wEYKqud2wiYSRNmNiBwzwbSZJew0nArU=; b=hwPfHRjnio4LvkkGgBcBW7BXXeHeA8t0FQQFL8RZgFSUH/RavHR5+sHwY02pX9CY4V EDv6PVWsf3dm8hZGTgFwTkw5uHOtEb34zBRff3cLANrJMzUkMtESZtpMFiYKNdHTRr/w HHdChB8BOqmxYyEyRLrxSzGMGIGr/AkUnzmiUnV3aKAIOISTitrSRFcRyiC2FoxhZc5y wBtQRZ6rOWI4N6GmuOT8HoUMhEKui67IqUAegwto5edvGPhbs+CgSXtRQfWB3ZcNqKYK xA9MSfSzBuu7/ry6jbBXNdioEEH7Oe0+EWR0t1d5kehE0EbsJ0+4x4DZGT7uiu7TK4hw a+FA== X-Forwarded-Encrypted: i=1; AJvYcCXeV6EgcWAXsu+hzf08FSqtIqUEIXuj+ZjmTXX3co+VreG5PNz9TwB86SLHFSvOfstRGVn4U0qP4OBz+loT5bfWxaYj X-Gm-Message-State: AOJu0YzMDkKz77O947doq/fmEqFHC0Ji5zjb7YvkF1YEvIBMU57xjwDQ DHNr4IWtL1WjPmiflct+oVEYBQ0E13y6W5icUQ0MXSc9/FlS6CgoTcD95/wc4Vz0FN9s9GE9edr lBTts03UKaUzrFknt/ujBhjOFo/4= X-Google-Smtp-Source: AGHT+IHjRA+ipPMOgBYWh3apgFCc+BEopVL4i+tLo1BuY4E1TS7oMh/5Ba+eUq5O+KBDRJt16PuXf5hXydkPSetzL9c= X-Received: by 2002:a05:6870:82a4:b0:259:8420:8e3b with SMTP id 586e51a60fabf-26891d3b2e9mr229009fac.21.1722521486670; Thu, 01 Aug 2024 07:11:26 -0700 (PDT) MIME-Version: 1.0 References: <247701dae3b2$a1ea1f50$e5be5df0$@gmail.com> In-Reply-To: From: Josh Cohen Date: Thu, 1 Aug 2024 10:11:15 -0400 Message-ID: To: Patrick Meenan , cxres@protonmail.com Cc: Julian Reschke , ietf-http-wg@w3.org Content-Type: multipart/alternative; boundary="00000000000054c565061e9fc9ad" X-W3C-Hub-DKIM-Status: validation passed: (address=joshco@gmail.com domain=gmail.com), signature is good X-W3C-Hub-Spam-Status: No, score=-5.1 X-W3C-Hub-Spam-Report: AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, DMARC_PASS=-0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1 X-W3C-Scan-Sig: puck.w3.org 1sZWWg-006xEh-20 7d6b283be5f57fb4f0dd6c65bb205cb3 X-Original-To: ietf-http-wg@w3.org Subject: Re: Method Mania Archived-At: Resent-From: ietf-http-wg@w3.org X-Mailing-List: archive/latest/52174 X-Loop: ietf-http-wg@w3.org Resent-Sender: ietf-http-wg-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: --00000000000054c565061e9fc9ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Rahul, All, Rahul, I'm reading your draft. All, When using h2 & h3, when the client does a request, at the messaging layer, what is the request line version string? Is it: GET / HTTP/2 GET / HTTP/3 Or GET / HTTP/1.1 GET / HTTP/1.1 Does the version string reflect the transport layer or messaging layer? If we add new methods, can we update the version string? On Wed, Jul 31, 2024 at 9:40=E2=80=AFPM Patrick Meenan wrote: > Breakage up and down the stack from interception on-device (AV software) > or MITM devices. > > I haven't rolled out new methods but, generally, the software makes > assumptions and tends to break when those assumptions break. > > We've seen it with content-encodings a few times. > > We saw it when software was expecting headers and post body to all be sen= t > in one socket write. > > The TLS example is similar to the write problem where the interceptor > doesn't buffer the stream and expects the full client hello in a single > read. > > In all cases it was mishandling of well-spec'd protocols but the > interceptors took shortcuts and broke. > > On Wed, Jul 31, 2024 at 9:32=E2=80=AFPM wrote: > >> Patrick, >> >> When you say, =E2=80=9CWe have seen it more often than I care to admit= =E2=80=A6=E2=80=9D, >> >> are you referring to failures due to HTTP methods, new frame types, or >> something else? >> >> >> >> With respect to TLS failures, are those actual TLS related failures or >> are they symptoms of the above problem? >> >> >> >> >> >> *From:* Patrick Meenan >> *Sent:* Sunday, July 28, 2024 9:35 AM >> *To:* Josh Cohen >> *Cc:* Julian Reschke ; ietf-http-wg@w3.org >> *Subject:* Re: Method Mania >> >> >> >> 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 ca= se, >> 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 hav= e >> 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 err= or >> out when seeing a method they don't understand (but, odds are, new frame= s >> 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 (wipin= g >> 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 wr= ote: >> >> 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 >> time 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 d= one a >> great job evolving the transport. That's created the foundation for thi= ngs >> 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/su= b. >> >> >> >> If we add new functionality that users and devs want, and makes admin >> life easier, that could be helpful in driving better implementations, an= d >> uptake of HTTP/2/3 and masque proxying. >> >> >> >> >> >> >> >> >> >> >> >> On Sat, Jul 27, 2024 at 10:07=E2=80=AFPM Julian Reschke >> wrote: >> >> On 27.07.2024 16:44, Patrick Meenan wrote: >> > >> > >> > On Sat, Jul 27, 2024 at 4:23=E2=80=AFAM Julian Reschke > > > 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 >> >> --=20 --- *Josh Co*hen --00000000000054c565061e9fc9ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Rahul, All,

Rahul, I'm reading your= draft.

All,

When using h= 2 & h3, when the client does a request, at the messaging layer, what is= the request line version string?

Is it:
GET / HTTP/2
GET / HTTP/3

Or
= GET / HTTP/1.1
GET / HTTP/1.1

Does the v= ersion string reflect the transport layer or messaging layer?
If we add new methods, can we update the version string?
<= div>



On Wed, Jul 31, 2024 at 9:40=E2= =80=AFPM Patrick Meenan <patmeena= n@gmail.com> wrote:
Breakage up and down the stack from intercepti= on on-device (AV software) or MITM devices.=C2=A0
I haven't rolled out new methods but, general= ly, the software makes assumptions and tends to break when those assumption= s break.=C2=A0

We've= seen it with content-encodings a few times.=C2=A0
<= br>
We saw it when software was expecting headers an= d post body to all be sent in one socket write.=C2=A0

The TLS example is similar to the write probl= em where the interceptor doesn't buffer the stream and expects the full= client hello in a single read.=C2=A0

In all cases it was mishandling of well-spec'd protocols = but the interceptors took shortcuts and broke.=C2=A0

On Wed, Jul 31, 20= 24 at 9:32=E2=80=AFPM <joshco@gmail.com> wrote:

Patrick,

When you say, =E2=80=9CWe have seen it= more often than I care to admit=E2=80=A6=E2=80=9D,

are you referring t= o failures due to HTTP methods, new frame types, or something else?<= u>

<= /u>=C2=A0

With respect to TLS failures, are those actual TLS related failures o= r are they symptoms of the above problem?

=C2=A0

=C2=A0

<= p class=3D"MsoNormal">From: Patrick Meenan <patmeenan@gmail.c= om>
Sent: Sunday= , July 28, 2024 9:35 AM
To:<= /b> Josh Cohen <joshco@gmail.com>
Cc: Julian Reschke <julian.reschke@gmx.de>; ietf-htt= p-wg@w3.org
Subject:= Re: Method Mania

=C2=A0

Sorry, I did= n't mean to imply not to go forward or to necessarily find a way to thr= ead the needle but to explicitly plan for there to be middle-boxes that bre= ak and to be deliberate about how to handle that case, even for HTTPS.

=C2=A0

Failing loudly, in obvious and testable ways is WAY= better than failing silently or in random ways. It makes it much easier fo= r 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 subse= t 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.

=C2=A0

I expect that new frame types for HTTP/2 and HTTP/3 would be more compat= ible 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).

=C2=A0

We have seen it more often than I care to admit, with the rollouts f= or HTTP/2, brotli, post-quantum TLS and now with compression dictionaries (= which, you'd think the brotli rollout would have prepared devices for h= andling content-encoding negotiation in a compatible way, but nope).=

=C2=A0

=

The devices tend to fail the connections in pai= nful ways, like closing the whole connection when it sees payload content i= t doesn't like (wiping out a bunch of multiplexed requests on a HTTP/2 = connection for example).

=C2=A0

Here is the site= we're currently sending IT admins to when they get reports of TLS fail= ures with the post-quantum rollout (mostly because of broken middleboxes):= =C2=A0https://tldr.fail/

=C2=A0

Same here..=C2=A0 Patrick also said:=

"The better question is under what circumstances do we want to allo= w those devices to "break" and force them to fix the implementati= ons?"

=C2=A0

Maybe a reasonab= le interpretation of Patrick's statement is that it's time to be=C2= =A0bold.=C2=A0=C2=A0HTTP/1.1 RFC2616 was published in 1999.=C2=A0 It= 's the 25 year anniversary.=C2=A0=F0=9F=A5=B3 =C2=A0In the intervening ye= ars, the IETF has done a great job evolving the transport.=C2=A0 That's= created the foundation for things we couldn't do back then.=C2=A0 =C2= =A0I don't think it was a coincidence that Lisa Dusseault was in the ro= om.=C2=A0 The universe is speaking to us.=C2=A0 Maybe it's time for a W= ebDAV re-spin..=C2=A0 The web could also have standardized pub/sub.=C2=A0= =C2=A0

=C2=A0<= /u>

If we add new functionality that u= sers and devs want, and makes admin life easier, that could be helpful in d= riving better implementations, and uptake of HTTP/2/3 and masque proxying.<= u>

=C2=A0

=

=C2=A0

=C2=A0

= =C2=A0

=C2=A0=

On Sat, Jul 27, 2024 at 10:07=E2=80=AFPM Julian Reschke &= lt;julian.reschk= e@gmx.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
> <mail= to:julian.reschk= e@gmx.de>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 26.07.202= 4 00:27, Josh Cohen wrote:
>=C2=A0 =C2=A0 =C2=A0 > On the httpwg a= genda at IETF 120 were a proposal for a new QUERY
>=C2=A0 =C2=A0 =C2= =A0method
>=C2=A0 =C2=A0 =C2=A0 > and Braid, which has subscriptio= n functionality that overloads
>=C2=A0 =C2=A0 =C2=A0the GET
>= =C2=A0 =C2=A0 =C2=A0 > method.
>=C2=A0 =C2=A0 =C2=A0 >
>= =C2=A0 =C2=A0 =C2=A0 > What I am curious about is if, at this point in t= he evolution of the
>=C2=A0 =C2=A0 =C2=A0 > web, it is now safe to= add new methods for new functionality.
>=C2=A0 =C2=A0 =C2=A0I've= been
>=C2=A0 =C2=A0 =C2=A0 > reading up on HTTP/2/3 and it seems = that nowadays, connections are
>=C2=A0 =C2=A0 =C2=A0 > end-to-end = secure and are essentially tunneled through middle boxes,
>=C2=A0 =C2= =A0 =C2=A0 > including HTTP/1.1 proxies. I'm still just wrapping my = head around
>=C2=A0 =C2=A0 =C2=A0 > MASQUE, but it looks like it c= an handle arbitrary methods.=C2=A0 Similarly
>=C2=A0 =C2=A0 =C2=A0 &g= t; origin servers have evolved to support arbitrary methods.
>
>= ;=C2=A0 =C2=A0 =C2=A0It always has been "safe", when https was us= ed.
>
>
> https is not "safe" in practical term= s because of middleboxes that
> intercept the connections. It is very= common in enterprise deployments
> where they install local trust an= chors on the client devices and use
> mitm software to inspect the tr= affic.
> ...

I meant "safe" wrt deploying new HTTP m= ethods.

When was the last time you encountered a problem?

Bes= t regards, Julian




=C2=A0

--

<= div>

---
Josh Cohen=C2=A0

<= /div>


--

---
<= b>Josh Cohen=C2=A0

--00000000000054c565061e9fc9ad--