Re: [core] block1 size negotiation with 4.13 Request Entity Too Large

[Achim Kraus <[e-mail]>]

Hi Jon,
Hi carsten,

thanks for the fast answers!

So, changing the block-number to compensate a blocksize change, is the
intended behavior.

 > I don’t know of any issues that the change in “num” would cause.

That may depend on the interpretation of,

RFC 7959, 2.3. Block Options in Requests and Responses

Block 2 / Request
"The NUM field in the Block2 Option gives the block number of
the payload that is being requested to be returned in the
response."

The interpretation may be, either
- the requested "block number" is to be returned in the response, or
- the payload of the request block is to be returned.

best regards
Achim

Am 07.01.21 um 22:16 schrieb Carsten Bormann:
> Hi Achim,
>
> On 2021-01-07, at 21:44, Achim Kraus <[e-mail]> wrote:
>>
>> Hi Carsten
>> Hi List,
>>
>> sorry for that late follow up of that question from last summer.
>> Currently I try to cleanup that code in Californium.
>> Doing so, I'm not sure, what the intended behaviour in the following
>> scenario should be:
>> - the client starts with a request "GET block2(num=5, size=256)".
>
> The operative word here is “starts with”.
> So this is the first time the server has a chance to react to the proposed block size.
>
> Section 2 of RFC 7959 says:
>
>     In most cases, all blocks being transferred for a body (except for
>     the last one) will be of the same size.  (If the first request uses a
>     bigger block size than the receiver prefers, subsequent requests will
>     use the preferred block size.)  The block size is not fixed by the […]
>
> This talks about the “first request”, which could be read as meaning “num=0”, but in this case clearly matches the premise.
>
>> - the server is configured to send blocks only up to 64 bytes.
>>
>> If that exchange would happen at num=0, it works fine to send just a
>> smaller response, but with "num=5", I'm not sure, what is intended.
>> So, does this result in:
>>
>> - the server respond with "CONTENT block2(num=?, size=64)"
>>   the issue with that is in my opinion, that either the "num" must
>>   be changed, or the offset can not longer calculated by
>>   option.num * option.size. To change the "num" may cause issues,
>>   though that "num" seems to be used to ACK the blocks.
>
> I don’t know of any issues that the change in “num” would cause.
> “Num” is just a terse encoding for the current byte position (*), based on “szx”, and when szx changes, num has to change in unison.
> (Jon is right that, with the size divided by four, the num needs to be multiplied by four to start filling in the right byte position(**).)
>
>> - the server respond with an error; but which one should be used?
>
> Since the protocol has been designed to enable stateless servers, we didn’t see a need to provide an error that a stateless server would never know what to use for.
>
> Grüße, Carsten
>
> (*) Well, that is just given as an “Implementation note” in Section 2.2, but I would expect a sane implementation to follow this note.
>
> (**) A prank implementation might try to fill in num=23 for size=64, as this is also part of the block 5 at size 256.  I don’t think that this behavior would be justifiable, as the case for num=0 clearly fills in the leftmost block.
>