-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request using Block1 triggers Block2 response #28
Comments
Some more inputs : RFC8132§2.5. Working with Block says :
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?
The text was updated successfully, but these errors were encountered: