Subject: [Masque] Extended CONNECT, Capsules in DATA, HTTP Upgrade Tokens

From: David Schinazi <[email-masked]>
Date: Mon, 9 Aug 2021 14:37:52 -0700

Hi folks,

I'm sending this email to MASQUE with WebTransport and HTTP lists as BCC,
please reply only on the MASQUE list, registration link here: [1].

At IETF 111, we had some discussions in both the MASQUE and WEBTRANS
working groups around how we should be reasoning about these protocols and
their interaction with HTTP: are we building inside HTTP or over HTTP?
Martin Thomson wrote up the implications in this email [2].

Most importantly, the difference in how we reason about these protocols led
to
the following questions which impact the wire encoding in non-compatible
ways:

1) Capsules. We've reached some level of agreement that MASQUE and
WebTransport need a mechanism to reliably exchange information
bidirectionally
between client and server, even in the presence of intermediaries. While
the draft
currently [3] uses a new HTTP/3 and HTTP/2 frame for this, there was
agreement in
the room that this should be instead sent over the DATA stream (i.e. inside
DATA
frames for HTTP/2 and HTTP/3). And here comes the architectural twist:
we're no
longer sending an HTTP request and response on the DATA stream, we're now
using a new protocol over that stream.

2) Methods. WebTransport currently uses Extended CONNECT (RFC 8441) while
MASQUE uses new methods (CONNECT-UDP and CONNECT-IP). There was general
agreement that it would make sense to pick the same option for both. A
pragmatic
argument was made that there are implementations out there that wait for
the FIN bit
before parsing the client's headers which would break on these new methods,
whereas
requiring SETTINGS_ENABLE_CONNECT_PROTOCOL ensures that we aren't
speaking to one such broken implementation.

I personally see these two questions converging on a common solution: we
unify on
Extended CONNECT and define a new protocol which is simply a sequence of
capsules. This closely mirrors how WebSockets work over HTTP/2, and seems to
make sense architecturally. It also allows us to support HTTP/1.1 by using
the same
protocol with Upgrade.

If we decide to go this route, I think we have two main options to make it
work:

A) we have a document that defines the capsule protocol and register it
with the
IANA HTTP Upgrade Token Registry, but we then need a way to differentiate
between
WebTransport, CONNECT-UDP and CONNECT-IP (and other future applications).
The simplest way could be to define a separate HTTP header to convey the
application.

B) we have a document that defines the capsule protocol but does not
register an
Upgrade Token, and then every application defines its own Upgrade Token and
specifies
that its DATA stream will use the capsule protocol.

The main benefit of having the capsule protocol defined in one place is
that we can
have a single 62bit IANA registry for Capsule Types instead of having every
single
application define its own.

Does anyone have thoughts or opinions in this space?

Thanks,
David

[1] https://www.ietf.org/mailman/listinfo/masque
[2]
https://mailarchive.ietf.org/arch/msg/webtransport/NIiRl91X3151ppT0lQZvTY0wJ8w/
[3] https://datatracker.ietf.org/doc/html/draft-ietf-masque-h3-datagram-03

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 9 Aug 2021 20:49:17 -0400

It seems to me that defining a single Upgrade Token supports innovation and
flexibility.  I don't know whether intermediaries "should" check :protocol,
but I imagine that many will reject the request if it's unrecognized.  If
every application has to mint a new upgrade token, I suspect that each new
application will find itself incompatible with many existing intermediaries.

On Mon, Aug 9, 2021 at 5:38 PM David Schinazi <[email-masked]>
wrote:

> Most importantly, the difference in how we reason about these protocols
> led to
> the room that this should be instead sent over the DATA stream (i.e.
> inside DATA
> before parsing the client's headers which would break on these new
> methods, whereas
> Upgrade Token, and then every application defines its own Upgrade Token
> and specifies
> have a single 62bit IANA registry for Capsule Types instead of having
> every single
> --
> Masque mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/masque
>

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 10 Aug 2021 10:57:06 +1000

On Tue, Aug 10, 2021, at 10:49, Ben Schwartz wrote:
> It seems to me that defining a single Upgrade Token supports innovation 
> and flexibility.  

I don't think that is addressing the right question.  The question I would ask is whether there are N protocols or 1 protocol (with options).  So far, I'm seeing N protocols that share design elements.  The extent to which those protocols share design elements is pretty high, so we should unify designs where we can (like choosing extended CONNECT), but I would stop short of defining an über-protocol unless or until it is shown that the N protocols are sufficiently similar.  Right now, I'm not seeing enough similarity between IP tunneling and WebTransport to justify making just one protocol.

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 9 Aug 2021 22:37:48 -0400

Just because the pseudo-header is named ":protocol" doesn't mean it's "the
protocol".  To decide what goes in that field, we need to figure out who
consumes it, and what they need to know, or not know.  Alas, RFC 8441
doesn't say anything about gateways, so the answer is not immediately
evident.

As an example, consider implementing an HTTP/3<->HTTP/1.1 gateway for
datagram-based applications.  This gateway needs to know about "capsules",
because it has to merge the datagrams into the HTTP body*.  Depending on
our choices here, this intermediary might need to be updated to support
every application that uses datagrams, or it might be forward-compatible to
all such applications.  I would strongly prefer the latter, and I think we
should use the :protocol field in ways that support this.

I don't know exactly how this plays out.  Perhaps :protocol is
per-application, and we instruct gateways to ignore :protocol and condition
their behavior on Content-Type or some other header.  Or perhaps we just
run MASQUE over WebTransport :-)

* in one direction, and extract them out of the body in the other direction.

On Mon, Aug 9, 2021 at 8:57 PM Martin Thomson <[email-masked]> wrote:

> I don't think that is addressing the right question.  The question I would
> ask is whether there are N protocols or 1 protocol (with options).  So far,
> I'm seeing N protocols that share design elements.  The extent to which
> those protocols share design elements is pretty high, so we should unify
> designs where we can (like choosing extended CONNECT), but I would stop
> short of defining an über-protocol unless or until it is shown that the N
> protocols are sufficiently similar.  Right now, I'm not seeing enough
> similarity between IP tunneling and WebTransport to justify making just one
> protocol.
>
> --
> Masque mailing list
> [email-masked]

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 10 Aug 2021 13:05:40 -0700

I agree with Martin’s sense here. Having unification on extended CONNECT makes sense, but these are different protocols.

Thanks,
Tommy

> On Aug 9, 2021, at 5:57 PM, Martin Thomson <[email-masked]> wrote:
>

---

From: David Schinazi <[email-masked]>
Date: Thu, 12 Aug 2021 12:25:58 -0700

Perhaps we need to step back and answer the question: what is a protocol?
Well maybe that's too vague, we don't need to go full TAPS here. So more
specifically, what does the Upgrade Token mean?
In the case of Extended CONNECT, the ":protocol" pseudo-header refers to
the semantics of the DATA stream. Upgrade in HTTP/1.1 has the same
semantics.
Back to capsules, the semantics of the DATA stream are "a sequence of
capsule TLVs". So if CONNECT/UDP and WebTransport share this, aren't they
the same "protocol" in this regard?
CONNECT/UDP and WebTransport differ in the semantics they apply to
datagrams, but does that mean they need different Upgrade Tokens, or just
that they need different registration capsules?

David

On Tue, Aug 10, 2021 at 1:05 PM Tommy Pauly <tpauly=
[email-masked]> wrote:

> I agree with Martin’s sense here. Having unification on extended CONNECT
> makes sense, but these are different protocols.
>
> Thanks,
> Tommy
>
> > I don't think that is addressing the right question.  The question I
> would ask is whether there are N protocols or 1 protocol (with options).
> So far, I'm seeing N protocols that share design elements.  The extent to
> which those protocols share design elements is pretty high, so we should
> unify designs where we can (like choosing extended CONNECT), but I would
> stop short of defining an über-protocol unless or until it is shown that
> the N protocols are sufficiently similar.  Right now, I'm not seeing enough

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 12 Aug 2021 22:22:16 +0100

Hey,

To pick up on one of David's points. I think a usable abstraction comes
from declaring "capsule" as the :protocol. Literally defining that as a
Token. And then defining the equivalent of sub-protocol negotiation in
capsule. Either via an additional header, like websockets does it (RFC
6455, section 1.9), or an inband mechanism.

Cheers,
Lucas

---

From: Victor Vasiliev <[email-masked]>
Date: Thu, 12 Aug 2021 18:02:07 -0400

I don't think this is that much of a useful abstraction by itself.  HTTP/3
implementations have to be aware of the additional features (datagrams,
WebTransport streams) in use in order to provide useful support for
specified protocols anyways.

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 12 Aug 2021 23:40:57 +0100

Hey Victor,

> specified protocols anyways.

The suggestions on the thread read to me as 1) use :protocol for describing
the meaning of data frame payload on the stream 2) use something else
(headers, or whatever) to describe everything else related to the specific
usage of that stream in the broader connection context.

Some of the things folks want to do need transport and
HTTP-version-specific features. But once a client is at a stage of being
able to make a request, both sides should have obtained information about
feature availability. Could you explain you point a bit more? Is this about
signalling something like "udp" in an extended connect request so the
server can verify that it, for example, really supports datagrams before
responding to the request with a 2xx?

Cheers,
Lucas

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 13 Aug 2021 10:47:36 -0500

I'm top-posting, partially to say that I think David is asking the right
questions here, but mostly to say that "Well maybe that's too vague, we
don't need to go full TAPS here" is a truly awesome contribution to the
discussion (and I say that as the former AD who chartered TAPS)!

Best,

Spencer

---

From: Victor Vasiliev <[email-masked]>
Date: Fri, 13 Aug 2021 12:37:11 -0400

I think the simplest case is H/{1,2} to H/3.  Imagine a box supports the
theoretical capsule protocol proposed here, but not more; in that case, it
would take the WebTransport-over-HTTP/2 encoding and just forward it over a
single HTTP/3 stream, instead of using proper WebTransport-over-HTTP/3.

On Thu, Aug 12, 2021 at 6:41 PM Lucas Pardue <[email-masked]>
wrote:

>> I don't think this is that much of a useful abstraction by itself.
>> HTTP/3 implementations have to be aware of the additional
>> features (datagrams, WebTransport streams) in use in order to provide
>> useful support for specified protocols anyways.
>>
>
> The suggestions on the thread read to me as 1) use :protocol for
> describing the meaning of data frame payload on the stream 2) use something
> else (headers, or whatever) to describe everything else related to the
> specific usage of that stream in the broader connection context.
>

---

From: David Schinazi <[email-masked]>
Date: Fri, 13 Aug 2021 09:50:42 -0700

Victor has a good point about intermediaries, which raises another question
for the HTTP experts here: are Upgrade Tokens hop-by-hop or end-to-end?

Another phrasing would be: are there WebSocket intermediaries out there that
- speak h2 with extended connected to the client
- speak h1 with Upgrade to the server
- convert :protocol to Upgrade without parsing the Upgrade Token
- forward the DATA stream between h2 and h1 without parsing its contents

I think we should strive to reach a situation where intermediaries only
need to be software-upgraded once for capsule (and datagram) support, then
everything else is end-to-end. Protocol-specific optimizations can exist,
but getting things functional-but-not-optimized for cheap is important.

Victor, reducing the work required for an intermediary to get WebTransport
to work is good. That way they can experiment with it, and if it
seems useful that's when they can convince their vendor to implement
"proper WebTransport-over-HTTP/3" (by which I assume you mean using
individual QUIC streams instead of the to-be-written version-agnostic
encapsulation of WebTransport streams inside capsules).

David

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 14 Aug 2021 12:32:41 +1000

Hey,

> On 14 Aug 2021, at 2:50 am, David Schinazi <[email-masked]> wrote:
> 
> Victor has a good point about intermediaries, which raises another question for the HTTP experts here: are Upgrade Tokens hop-by-hop or end-to-end?

<https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#field.upgrade>: A sender of Upgrade must also send an "Upgrade" connection option in the Connection header field (Section 7.6.1) to inform intermediaries not to forward this field. A server that receives an Upgrade header field in an HTTP/1.0 request must ignore that Upgrade field.

> I think we should strive to reach a situation where intermediaries only need to be software-upgraded once for capsule (and datagram) support, then everything else is end-to-end. Protocol-specific optimizations can exist, but getting things functional-but-not-optimized for cheap is important.

I think it's worth examining that goal a bit. It seems like everyone agrees that reusing the same overall framework for different use cases ('protocols') is reasonable here; the question is whether new protocols should be deployable through intermediaries without any changes to them.

On the face of it that's reasonable and good. However, we should recognise that gateways -- i.e., reverse proxies and CDNs -- can accommodate new protocols that don't require a lot of code  pretty easily because they're working in concert with the origin, and will probably want to do so explicitly (so that they can manage the rollout). So the cost of requiring something like a new upgrade token is really low for them.

The question is what we want proxies to do here. Traditional forward proxy caches aren't widely deployed any more, because forward proxy caching has little benefit in a most-encrypted world. Likewise for interception caches. Instead, the common use case for proxies is when policy is being imposed --  either locally (e.g., virus scanner) or on the network. They're not as likely to support new protocols quickly, and so it's attractive to design something that doesn't require modification by them to pass through.

Is that realistic? I can only imagine that people who are designing intermediaries with policy imposition in mind aren't going to be thrilled about implementing and supporting a new protocol that allows arbitrary, opaque data through. Of course, if they understand the protocol and have the appropriate key material, they'll eventually add it as a feature, but I can't see them allowing opaque data to pass through by default -- especially when they have to actively implement something to do so. 

That's not to say that making it a single protocol from the perspective of intermediaries is a _bad_ thing -- just that it may not get us where we hope it will.  And, of course, using :protocol and Upgrade tokens to identify protocols also avoids creating a situation where we have three or more layers of abstraction hiding that protocol...

Popping up a layer, I agree that extended CONNECT is a reasonable way to go for these capabilities. All of these use cases have the core semantic of 'connection'; each can be viewed as having different parameterisation. I think it also aligns with the text in http-core.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 16 Aug 2021 10:31:05 +1000

On Sat, Aug 14, 2021, at 12:32, Mark Nottingham wrote:
> Is that realistic? I can only imagine that people who are designing 
> intermediaries with policy imposition in mind aren't going to be 
> thrilled about implementing and supporting a new protocol that allows 
> arbitrary, opaque data through. 

I can see proxies deciding on a per-protocol basis.  That is, they will look at :protocol and make a decision.  At that point, the content of the protocol could be entirely different.  Choosing to align the design of different protocols will make it easier to implement, but my sense is that policy is the primary reason things don't work, not implementation complexity.

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 16 Aug 2021 13:30:32 -0400

On Fri, Aug 13, 2021 at 10:32 PM Mark Nottingham <[email-masked]> wrote:

> > Victor has a good point about intermediaries, which raises another
> question for the HTTP experts here: are Upgrade Tokens hop-by-hop or
> end-to-end?
>
> <
> https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#field.upgrade>:
> A sender of Upgrade must also send an "Upgrade" connection option in the
> Connection header field (Section 7.6.1) to inform intermediaries not to
> forward this field. A server that receives an Upgrade header field in an
> HTTP/1.0 request must ignore that Upgrade field.
>
>
> I think it's worth examining that goal a bit. It seems like everyone
> agrees that reusing the same overall framework for different use cases
> ('protocols') is reasonable here; the question is whether new protocols
> should be deployable through intermediaries without any changes to them.
>
> On the face of it that's reasonable and good. However, we should recognise
> that gateways -- i.e., reverse proxies and CDNs -- can accommodate new
> protocols that don't require a lot of code  pretty easily because they're
> working in concert with the origin, and will probably want to do so
> explicitly (so that they can manage the rollout). So the cost of requiring
> something like a new upgrade token is really low for them.

I understand the theory of this, but in practice I'm not sure it has come
true.  For example, CDN gateways all seem to have a very limited set of
supported methods.

I think the existence of even a small barrier to deployment here is
actually highly ossifying.  New use cases start very small, too small to
justify any modification to a CDN operator's infrastructure.  Customers, in
the absence of this new feature, find a workaround.  This leaves demand for
the "real deal" very low, and so CDN infrastructure changes happen very
slowly, even if they could have been trivial.

I see this, for example, in the history of WebSocket (which took many years
to deploy on CDNs) and long-polling libraries like Socket.IO (which
provided an escape hatch for many use cases, in a less standardized
fashion).  I also see it in the use of POST for everything under the
sun, rather than making new methods with specialized semantics.

If WebTransport is standardized as one :protocol, and CONNECT-UDP as
another, and CONNECT-IP as another, etc., I expect that in practice only
WebTransport will be widely available, and the other functionalities will
have to be reimplemented on top of WebTransport, no matter what we say.

---

From: Victor Vasiliev <[email-masked]>
Date: Mon, 16 Aug 2021 18:53:24 -0400

I don't believe making sure that all intermediaries that support one of
{MASQUE, WebTransport} would get another for free is a useful goal; the
kinds of scenarios in which those would be used are very different, and
besides, as I pointed out, this only really works in one direction.

HTTP intermediaries are, at their core, not L4 middleboxes; they are
L7-aware parties with an active interest in making things work, as they
have to be explicitly put in place by either the client or the server.  The
intermediaries that need to support
MASQUE/WebTransport/NewDatagramProtocol2030/etc will implement it, QA it,
find all the edge cases, integrate it into any instrumentation they provide
and continuously support that; all other protocols would only work by
accident at best.

(enterprise proxies that enforce policy are an exception, but given their
goal and the fact that they have the encryption keys, I don't think there's
much we can do about them)

On Mon, Aug 16, 2021 at 1:30 PM Ben Schwartz <[email-masked]> wrote:

>> On the face of it that's reasonable and good. However, we should
>> recognise that gateways -- i.e., reverse proxies and CDNs -- can
>> accommodate new protocols that don't require a lot of code  pretty easily
>> because they're working in concert with the origin, and will probably want
>> to do so explicitly (so that they can manage the rollout). So the cost of
>> requiring something like a new upgrade token is really low for them.
>
>
> I see this, for example, in the history of WebSocket (which took many
> years to deploy on CDNs) and long-polling libraries like Socket.IO (which

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 17 Aug 2021 08:55:20 +1000

> On 17 Aug 2021, at 8:53 am, Victor Vasiliev <[email-masked]> wrote:
> 
> (enterprise proxies that enforce policy are an exception, but given their goal and the fact that they have the encryption keys, I don't think there's much we can do about them)

Right. One thing to consider is how they'll fail -- e.g., if they fail to negotiate a protocol they don't support, that's pretty easy to detect and reliable. If they block protocols they don't understand based upon heuristics, that's messier.

Cheers,

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 17 Aug 2021 10:45:29 +1000

On Tue, Aug 17, 2021, at 08:55, Mark Nottingham wrote:
> Right. One thing to consider is how they'll fail -- e.g., if they fail 
> to negotiate a protocol they don't support, that's pretty easy to 
> detect and reliable. If they block protocols they don't understand 
> based upon heuristics, that's messier.

Thankfully, we are providing them with a clear and unambiguous way of identifying the protocol in use.  The need for heuristics - at least at the level of identification - should be minimal.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 17 Aug 2021 10:46:49 +1000

> On 17 Aug 2021, at 3:30 am, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> I think the existence of even a small barrier to deployment here is actually highly ossifying.  New use cases start very small, too small to justify any modification to a CDN operator's infrastructure.  Customers, in the absence of this new feature, find a workaround.  This leaves demand for the "real deal" very low, and so CDN infrastructure changes happen very slowly, even if they could have been trivial.
> 
> I see this, for example, in the history of WebSocket (which took many years to deploy on CDNs) and long-polling libraries like Socket.IO (which provided an escape hatch for many use cases, in a less standardized fashion).  I also see it in the use of POST for everything under the sun, rather than making new methods with specialized semantics.

There's not a small difference between WebSockets and HTTP, from the standpoint of a CDN; it's not just a matter of looking and a header and passing it through...

> If WebTransport is standardized as one :protocol, and CONNECT-UDP as another, and CONNECT-IP as another, etc., I expect that in practice only WebTransport will be widely available, and the other functionalities will have to be reimplemented on top of WebTransport, no matter what we say.

Do you see CDNs as participating in CONNECT-UDP and CONNECT-IP in a manner that's identical in *all* ways as how they implement WebTransport? I suspect there are a fair number of differences...

As far as non-CDN intermediaries (i.e., enterprise MITM, as discussed) go, I agree that there will be some folks who need to tunnel -- but that's pretty unavoidable, no matter what we do.

Cheers,

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 16 Aug 2021 21:33:10 -0400

> [email-masked]> wrote:

...

> Do you see CDNs as participating in CONNECT-UDP and CONNECT-IP in a manner
> that's identical in *all* ways as how they implement WebTransport?

Yes, if their architectures are truly moved into alignment.  Capsules and
datagrams are uncacheable and strictly end-to-end, so a standards-compliant
gateway doesn't care what's in them or what they're for.  They just get
passed between client and origin without inspection.

I can imagine something like a Web Application Firewall that dives into the
contents and searches for scary patterns, but that is not a
standards-compliant gateway.

On Mon, Aug 16, 2021 at 6:53 PM Victor Vasiliev <[email-masked]> wrote:

> kinds of scenarios in which those would be used are very different
>

I think that this position (which I would summarize as "CONNECT-IP through
a CDN is not useful") is likely to be a common view, but I specifically
want CONNECT-IP through a CDN.  But because this use case seems weird to a
lot of people, I also think that it's going to be hard to get widely
deployed if CDNs have to be convinced to enable it explicitly.  The
potential customer base is too small, and the architecture too unusual.
This is how ossification happens.

I think it would help a lot if the protocol made it abundantly clear that
standards-compliant gateways have no interest in this distinction.

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 17 Aug 2021 10:43:11 +0900

2021年8月17日(火) 10:33 Ben Schwartz <bemasc=[email-masked]>:

>> Do you see CDNs as participating in CONNECT-UDP and CONNECT-IP in a
>> manner that's identical in *all* ways as how they implement WebTransport?
>
>
> I can imagine something like a Web Application Firewall that dives into
> the contents and searches for scary patterns, but that is not a

I think I might be missing something, but please let me ask a question: why
does an intermediary need to care if capsules are being used?

IIUC, the assumption that we have is that these capsules would be sent as
payloads of DATA frames. Then, I do not think there is much benefit in
exposing to the intermediaries the fact that the payloads of DATA frames
are capsules.

If an intermediary wants to pass through all tunnelling protocols, it can
do so by simply forwarding the payloads carried by DATA frames.

-- 
Kazuho Oku

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 17 Aug 2021 13:38:28 +1000

> On 17 Aug 2021, at 11:33 am, Ben Schwartz <[email-masked]> wrote:
> 
>> Do you see CDNs as participating in CONNECT-UDP and CONNECT-IP in a manner that's identical in *all* ways as how they implement WebTransport?
> 
> Yes, if their architectures are truly moved into alignment.  Capsules and datagrams are uncacheable and strictly end-to-end, so a standards-compliant gateway doesn't care what's in them or what they're for.  They just get passed between client and origin without inspection.

Ah, OK. You're taking about treating the CDN like a tunnel and hiding traffic in it, without doing anything to it -- fair enough. That implies that at the HTTP layer, you not only want encapsulation to work exactly the same way (so it only has to be implemented once), but also that routing works too -- some backend is configured and the traffic gets routed there; the host header / :authority are only used to identify what that backend service is.

Personally, I think that these use cases are *much* more interesting when the CDN routes to the next hop rather than relying on a backend server, but I get why you want maximal coverage, and creating a generic layer as you propose doesn't stop them from doing that.

> I can imagine something like a Web Application Firewall that dives into the contents and searches for scary patterns, but that is not a standards-compliant gateway.

The phrase 'standards-compliant gateway' is a bit self-contradictory; what gateways do to glue two protocols together is pretty much up to them :)  That said, a profile of what CDNs commonly do is emerging (and we're trying to slowly nudge that towards standards).

Cheers,