Request using Block1 triggers Block2 response

[mrdeep1]

What should be done for the request for the next Block2 data of the server payload after the request payload has been transferred and has had the NUM=0 Block2 response?

• Not include the Block1'd data in the request for the next block?
• Include the Block1'd data in the request for the next block?

Case for NOT including the data RFC7959 2.7 Combining Block1 and Block2

   In PUT and particularly in POST exchanges, both the request body and
   the response body may be large enough to require the use of block-
   wise transfers.  First, the Block1 transfer of the request body
   proceeds as usual.  In the exchange of the last slice of this block-
   wise transfer, the response carries the first slice of the Block2
   transfer (NUM is zero).  To continue this Block2 transfer, the client
   continues to send requests similar to the requests in the Block1
   phase, but leaves out the Block1 Options and includes a Block2
   request option with non-zero NUM.

as Block1 option is not allowed and hence no data payload in the subsequent request for the next block. Certainly true for PUT and POST.

RFC 9177 10.3.3 Handling Recovery states

   Note that, following (https://www.rfc-editor.org/rfc/rfc7959#section-2.7, the FETCH request does
   not include the Q-Block1 or any payload.

Case FOR including the data RFC 8132 2.3.2 The ETag Option

                                          The FETCH payload is input to
   that selection process and therefore needs to be part of the cache
   key.

so at least one cache-key which includes the payload needs to be maintained by the server.

Furthermore, it is reasonably clear for a FETCH doing an Observe request using Block1 has to send the entire FETCH payload when de-registering the Observe Request RFC 7641 3.6 Cancellation

                 a client MAY explicitly deregister by issuing a GET
   request that has the Token field set to the token of the observation
   to be cancelled and includes an Observe Option with the value set to
   1 (deregister).  All other options MUST be identical to those in the
   registration request except for the set of ETag Options.  When the
   server receives such a request, it will remove any matching entry
   from the list of observers and process the GET request as usual.

as updated by RFC 8132 2.4 Working with Observe

   The Observe option [RFC7641] can be used with a FETCH request as it
   can be used with a GET request.

What is the right answer here with the FETCH payload (which can span multiple Block1s) for requesting a subsequent block?
Is that then consistent with POST and PUT as per RFC 7959?

[sbernard31]

Some more inputs :

RFC8132§2.5. Working with Block says :

The Block1 option [RFC7959] can be used with a FETCH request as it
would be used with a POST request; the Block2 option can then be used
as it would with GET or POST.

At least to me, it's hard to imagine that repeating all block1 sequence for each block2 request could be a good "default" behavior.

Maybe it eventually makes sense for some FETCH stateless implementation (at cost of more traffic) ? In that case it should maybe better that this kind of server ask for repeating payload explicitly.

Just to better understand the situation, Is there other use case where repeating all block1 sequence would be needed ?