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

[Carsten Bormann <[e-mail]>]

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.