Re: Method Mania

["Soni L." <[e-mail]>]

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. <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>
>
>     On 2024-07-27 11:44, Patrick Meenan wrote:
>>
>>
>>     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.
>     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
>