Re: reserved flags and extensions

Hi Poul-Henning,

On Sun, Jul 13, 2014 at 08:36:23PM +0000, Poul-Henning Kamp wrote:
> The problem with low-fidelity implementations is that they, as the
> name says, are not going to pay a lot of attention to what we write
> they should do.

But at least they'll have to read the spec, so a few big warnings
for them to tell them how to remain reliable can be read, and can
be applied if the cost is low.

> We sort of have an unstated (should we?) principle so far of "I
> allow but You choose" attitude to variance from the base protocol,
> if we stick to that, all extensions/variances MUST be announced
> in SETTINGS, but the other end is not obligated to actually use them.
> 
> Given that, low-fidelity proxies can simply strip anything from
> SETTINGS they don't understand.

That was my goal, but for having seen lazy firewalls write "XXX"
over header fields or values because they were not able to change
the contents size, I'd rather suggest we offer an option for the
laziest possible implementation. Either we have some fill byte
to clear these extensions (why not, TCP has a NOP for that). And
we can simply insist that they must clear reserved bits even if
they are tunnels. In short : if you understand the framing you
must apply the senders' rules.

Maybe something along these lines :

   HTTP/1 did not allow multiple outstanding requests, allowing some
   products to work as tunnels and inspect contents on the fly. HTTP/2
   is a multiplexed protocol, and content inspectors will have to parse
   the framing. Any product which has to remain synchronized with the
   framing must comply with the rules that apply to any sender :
      - clear all reserved bits from outgoing frames (these bits will
        likely be used to negociate a different frame format with the
        other end).

      - trim extensions they do not know/support from settings frames
        (since these extensions may be used to change the framing).
        [ insert here how to easily trim extensions ]

Willy

Received on Monday, 14 July 2014 06:32:10 UTC