Closed szysas closed 9 months ago
Patch coverage: 97.56%
and project coverage change: +0.03%
:tada:
Comparison is base (
947f8bc
) 92.84% compared to head (163393e
) 92.87%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
I understand that you implement,
For echo
Option:
At client side, if server send 4.01 Unauthorized + Echo Option
resend request with Echo
option.
For Request-tag
Option:
At client side, for block1(only?) you automatically add request-tag
option.
At server side, if client send concurrent block request, you only keep the more recently started transfer (like before) and now you are able to reject old block request (identified by request-tag
) with 408 REQUEST_ENTITY_INCOMPLETE
.
Right ?
I understand that request-tag
is only needed for coap+tcp, if you want to be able to do concurrent transfert :
Note that this mechanism is implicitly implemented when the security layer guarantees ordered delivery (e.g., CoAP over TLS [RFC8323]). This is because, with each message, any earlier message cannot be replayed any more, so the client never needs to set the Request-Tag option unless it wants to perform concurrent operations.
(From : https://www.rfc-editor.org/rfc/rfc9175#section-3.5.1)
So I don't know if you want to add request-tag
automatically with coap+tcp ?
I understand that you implement,
For
echo
Option: At client side, if server send4.01 Unauthorized + Echo Option
resend request withEcho
option.For
Request-tag
Option: At client side, for block1(only?) you automatically addrequest-tag
option. At server side, if client send concurrent block request, you only keep the more recently started transfer (like before) and now you are able to reject old block request (identified byrequest-tag
) with408 REQUEST_ENTITY_INCOMPLETE
.Right ?
Exactly.
So I don't know if you want to add request-tag automatically with coap+tcp ?
With current change, it is not used in coap+tcp as that has a different builder class (CoapServerBuilderForTcp
)