[core] Stateless proxy and Request-Tag

[Christian Amsüss <[e-mail]>]

Hi Klaus and CoRE,

in preparation for an ERT -08 I also revisited the section on stateless
proxies (which we claim to be possible for blockwise transfers by adding
the Request-Tag disambiguator to all block-wise requests).

Whenever there is Block1 involved, things are good -- all request
messages carry a block-wise option, and the proxy adds a Request-Tag.

When there is no Block1 involved and the clien doesn't send early size
negotiation, we get requests without any block options. As we describe
it now, the proxy wouldn't add a Request-Tag (for it'd need to add it on
*all requests* otherwise). The client gets its first block back, and
starts asking for the second one. Only then, the proxy knows it's
blockwise and adds a Request-Tag.

That's fine for operations that are random-access on the server side
(for which Request-Tag wouldn't be needed but the proxy can't tell), but
for non-random-access operations, that incurs the risk of getting a
"Sorry can't server Block2:1 as you didn't reqeust Block2:0 before"
(which is atypical in GET scenarios but likely in POST ones).

There might be trivial recovery in some scenarios where a client sees
that and retries with a Block2:0 ab initio (providing such a retry is
safe to do), but a) that may trigger whichever action twice, b) is two
round-trips later, and c) I don't know whether clients actually behave
that way.

Sending a Request-Tag all the time would be vast overkill. With
Extended-Token-as-an-option we wouldn't need this at all, but as
mentioned yesterday, that boat probably sailed (though I don't remember
the reasons any more).

What to do about that? Don't know right now. Ideas welcome.

KR
c

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom