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

Thx Carsten for the answer.

This is clearer to me.
Some last point which is still not clear to me.

If a client send a request and a server answer with 4.13 without any 
option (no block1 no size1).
Should the client try to send the same request using block1 ? or as 
there is not a block1 option in the response it should not try to do 
that and just consider the request as a failure.

Le 22/07/2020 à 13:08, Carsten Bormann a écrit :
> Hi Achim,
>
> Good questions.
>
>> On 2020-07-22, at 09:56, Achim Kraus <achimkraus@gmx.net> wrote:
>>
>> Dear list,
>>
>> I would really appreciate, if the detail questions about the 4.13
>> failover could be answered!
>>
>> Without answers, I'm still afraid, that implementations will became
>> "overcomplicated" and "less interoperable".
>>
>> 1. is it intended to change the block size only in the first exchange?
>> Or on other exchanges? (Additionally, if changing later is considered as
>> failure, how should that failure be handled/processed?)
> RFC 7959 says (Section 2):
>
>     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
>     protocol. […]
>
> Simon cited some more text, but this is about too many blocks, not about too big blocks.  So it is not forbidden to request a smaller block size later.  I would expect that this is a rather unusual case, so I would not be surprised if a client gives up if this happens in mid-transfer.  On the other hand, it is also not hard to enable a client to adapt.
>
>> 2. is it intended, that a 4.13 response without block1 option to a
>> request also without block1 option, should also use/try a failover with
>> a request with block 1 option?
> That’s what RFC 7959 says:
>
>     The error code 4.13 (Request Entity Too Large) can be returned at any
>     time by a server that does not currently have the resources to store
>     blocks for a block-wise request payload transfer that it would intend
>     to implement in an atomic fashion.  (Note that a 4.13 response to a
>     request that does not employ Block1 is a hint for the client to try
>     sending Block1, and a 4.13 response with a smaller SZX in its Block1
>     Option than requested is a hint to try a smaller SZX.)
>
> This is phrased as a note, because the response contains a hint; there is no requirement that Block1 is supported.
>
> Simon also asked:
>
>>    2) What exactly should send the server ? 4.13 or 4.13 + block1 with szx option ? is size1 should be used to guess the correct block size ?
> I would expect that the server should send the desired block size if it wants the client to change from the block size it used, so 4.13 + Block1.  Size1 is not about block size, but about the size of the whole body - if the server has a limitation there, it might want to error out on a 4.13 (without a Block1 option).
>
> Grüße, Carsten
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core