Re: Method Mania

[Patrick Meenan <[e-mail]>]

On Sat, Jul 27, 2024 at 4:23 AM Julian Reschke <[e-mail]>
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.