Description
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?