Open mrdeep1 opened 1 year ago
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 ?
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?
Case for NOT including the data RFC7959 2.7 Combining Block1 and Block2
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
Case FOR including the data RFC 8132 2.3.2 The ETag Option
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
as updated by RFC 8132 2.4 Working with Observe
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?