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
Use of Request-Tag for handling multiple Block2 responses #77
Comments
I don't have the whole set of block mechanisms on the top of my head right now, but don't you need to send the request payload again and again when fetching the subsequent response blocks, thus giving the server all the information needed to match the requests? |
Yes, the request payload (with just the different Block2 num) needs to be repeated until the whole of the body comes in - in effect, the cache-key needs to be the same for all the individual payload requests. Here, I have 2 different payloads being returned (which are being transferred in the same time frame). Unless there is a varied proxy-safe elective option (unique the 2 different requests), it is not possible to request the next block specific to a particular returning payload. Hence, If I could use different Request-Tag (so different effective cache-keys) in the initial different requests (but to the same resource), I can ask for a specific block out of a specific response and match it up with the individual request. But, as I am not allowed to use Request-Tag if there is not a Block[12] option in the request, I cannot go down that path. Hence the question about why the MUST should be ther. |
Maybe adding some examples also for the "request-tag" part will bring additional clarity.
|
On 2021-12-20, at 18:49, Achim Kraus ***@***.***> wrote:
adding some examples
If we don’t want to delay the RFC editor process (*), we could start a new document with these now.
Grüße, Carsten
(*) There are a few people ready to do unspeakable acts if you do that.
https://www.rfc-editor.org/cluster_info.php?cid=C280
Please note the date of the first document in that cluster…
|
:-). It was just a "maybe". |
For the record, this is being addressed in AUTH48, pending approval of the authors and AD:
|
I have run into an issue where multiple CoAP requests (not needing Block1) to the same resource trigger potentially different responses that require the use of Block2. If the responses overlap, then there is confusion as to how to pull back the correct response to match the request. For example (grossly simplifying things)
POST /api//read payload = { 'offset': 0, 'count': 1200 }
POST /api//read payload = { 'offset': 2000, 'count': 1300 }
Or
FETCH /api//read payload = { 'offset': 0, 'count': 1200 }
FETCH /api//read payload = { 'offset': 2000, 'count': 1300 }
RFC7959 2.4 rightly states
Which then brings in the possible use of Request-Tag option in the request as a proxy-safe elective option. However.
draft-ietf-core-echo-request-tag -14 3.2 states
Which implies that the examples above need to contain the Block1 option in the first instance if there is any suspicion that Block2 is needed in the response.
Then draft-ietf-core-echo-request-tag -14 3.4 states
Apart from being hard to parse (what does “those” refer to?), this tells me that Servers MUST ignore requests that have no Block option – so, I cannot just add the Request-tag option to a request on the off-chance there may be a Block2 needed response.
Is there a good reason for this MUST?
If it is too late for the draft to be updated, the only easy way forward that I can see is to add in an unneeded Block1 to the request, or to add in a Block2 option to the request so the Request-Tag can be used even if the response fits into a single payload.
The text was updated successfully, but these errors were encountered: