Fix Block1 transfer handling for non-piggybacked responses #394
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
The node-coap client was incorrectly handling Block1 transfers when servers send non-piggybacked responses. Specifically, when a server:
The client would prematurely complete the Block1 transfer because it only processed Block1 options on ACK messages.
Root Cause
The condition
if (block1 != null && packet.ack)inlib/agent.tswas too restrictive. It only processed Block1 options when the packet was an ACK, but RFC 7959 allows Block1 responses to be sent as separate messages (non-piggybacked).Solution
Changed the condition to
if (block1 != null)to process Block1 options regardless of message type. This handles:RFC Compliance
According to RFC 7959 (Block Transfer), Block1 responses can be sent either:
The fix ensures compliance with both approaches.
Testing
Files Changed
lib/agent.ts: Modified Block1 processing condition to handle all message typesThis fix resolves issues when communicating with third-party CoAP servers that implement non-piggybacked Block1 responses.