Subject: [core] Stateless proxy and Request-Tag

From: Christian Amsüss <[email-masked]>
Date: Thu, 31 Oct 2019 14:36:56 +0100

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

---

From: 'Christian Amsüss' <[email-masked]>
Date: Thu, 31 Oct 2019 15:50:48 +0100

> Isn't this the ETag not Request-Tag?

This is about the server knowing which response to send back out. In the
later phase of a Block1+2 operation, there is neither Block1 nor a
payload sent with the requests that pull out the rest of the response
body. The server, in the proxy-less case, would rely on the endpoint to
know which operation those belong to, and would need a Request-Tag to
tell them apart.

A stateless proxy couldn't tell whether those later Block2 come from the
tail of a Block1+2 operation or from a Block2-only one, so it would send
a Request-Tag.

(I originally thought it could tell that it's not definitely not a
Block1+2 follow-up if there is a non-empty payload in the Block2:>0
requests, but reading RFC7959 Section 2.4 again -- is there, at all?
There's no example of a non-zero-but-non-block1-either exchange in the
spec; "the requester may retrieve additional blocks of the resource
representation by sending further requests with the same options as the
initial request and a Block2 Option giving the block number and block
size desired" but doesn't tell about payload. I feel I should know that
for certain but am embarassed I don't).

KR
c

---

From: Jim Schaad <[email-masked]>
Date: Thu, 31 Oct 2019 08:28:51 -0700

If it is a fetch then it has payload

-----Original Message-----
From: 'Christian Amsüss' <[email-masked]> 
Sent: Thursday, October 31, 2019 7:51 AM
To: Jim Schaad <[email-masked]>
Cc: Core WG mailing list <[email-masked]>
Subject: Re: [core] Stateless proxy and Request-Tag

This is about the server knowing which response to send back out. In the
later phase of a Block1+2 operation, there is neither Block1 nor a payload
sent with the requests that pull out the rest of the response body. The
server, in the proxy-less case, would rely on the endpoint to know which
operation those belong to, and would need a Request-Tag to tell them apart.

A stateless proxy couldn't tell whether those later Block2 come from the
tail of a Block1+2 operation or from a Block2-only one, so it would send a
Request-Tag.

(I originally thought it could tell that it's not definitely not a
Block1+2 follow-up if there is a non-empty payload in the Block2:>0
requests, but reading RFC7959 Section 2.4 again -- is there, at all?
There's no example of a non-zero-but-non-block1-either exchange in the spec;
"the requester may retrieve additional blocks of the resource representation
by sending further requests with the same options as the initial request and
a Block2 Option giving the block number and block size desired" but doesn't
tell about payload. I feel I should know that for certain but am embarassed
I don't).

KR
c

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

---

From: 'Christian Amsüss' <[email-masked]>
Date: Thu, 31 Oct 2019 16:38:42 +0100

> If it is a fetch then it has payload

In the Block2:1 request? That's good to hear b/c that's what I thought
but couldn't support.

Still, that leaves any messages that are Block2:>0 with an empty payload
undecidible for a proxy (could be tail of Block1+2, could be just tail
of Block2 and the request body is just empty), on which it'd need to
tack a Request-Tag, so as to ensure that the correct result of an
earlier Block1+2 operation is pulled out of the server.

(I'm not saying I'd advocate build servers that have such statefullness,
but 7959 allows such constructs, and I'd like to see all of that work
through a stateless proxy.)

KR
c

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 31 Oct 2019 17:59:11 +0100

I don’t understand how Request-Tag became necessary for Block2.
For me that is a Block1-only addition.

Grüße, Carsten