Re: [core] block1 size negotiation with 4.13 Request Entity Too Large
Simon Bernard <contact@simonbernard.eu> Wed, 22 July 2020 12:43 UTC
Return-Path: <contact@simonbernard.eu>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 049F23A0B2E for <core@ietfa.amsl.com>; Wed, 22 Jul 2020 05:43:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.553
X-Spam-Level:
X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJRnWs3ZU5KS for <core@ietfa.amsl.com>; Wed, 22 Jul 2020 05:43:19 -0700 (PDT)
Received: from smtpout1.mo804.mail-out.ovh.net (smtpout1.mo804.mail-out.ovh.net [79.137.123.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B83B43A0B2D for <core@ietf.org>; Wed, 22 Jul 2020 05:43:19 -0700 (PDT)
Received: from mxplan6.mail.ovh.net (unknown [10.109.143.188]) by mo804.mail-out.ovh.net (Postfix) with ESMTPS id 88A2E4F2012B; Wed, 22 Jul 2020 14:43:16 +0200 (CEST)
Received: from simonbernard.eu (37.59.142.105) by DAG3EX2.mxp6.local (172.16.2.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Wed, 22 Jul 2020 14:43:15 +0200
Authentication-Results: garm.ovh; auth=pass (GARM-105G0069423a566-cab7-4989-8d3a-39aebbb562d1, 08996888EDA5D2FB315D7FC10310BD13FAB8CF26) smtp.auth=contact@simonbernard.eu
To: Carsten Bormann <cabo@tzi.org>, Achim Kraus <achimkraus@gmx.net>
CC: "core@ietf.org" <core@ietf.org>
References: <189d3f1e-9c83-b1c7-d8a1-7f195265bd2d@gmx.net> <e017c262-c88e-6d77-5f05-2ae2c1145aa8@gmx.net> <AA7B14A4-575F-465F-A106-3A6048877F79@tzi.org>
From: Simon Bernard <contact@simonbernard.eu>
Message-ID: <8e2a0b3b-8f22-d381-d035-999e9c80b79e@simonbernard.eu>
Date: Wed, 22 Jul 2020 14:43:14 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <AA7B14A4-575F-465F-A106-3A6048877F79@tzi.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Originating-IP: [37.59.142.105]
X-ClientProxiedBy: DAG9EX1.mxp6.local (172.16.2.81) To DAG3EX2.mxp6.local (172.16.2.22)
X-Ovh-Tracer-GUID: e9d26387-ba59-4327-aa99-49c242b69beb
X-Ovh-Tracer-Id: 3775142390407903453
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduiedrgeelgdehiecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefuvfhfhffkffgfgggjtgfgihesthekredttdefjeenucfhrhhomhepufhimhhonhcuuegvrhhnrghrugcuoegtohhnthgrtghtsehsihhmohhnsggvrhhnrghrugdrvghuqeenucggtffrrghtthgvrhhnpeegjeelkeethfelveejveekgfeftedthfdtveegvedtteegkeeuvdfftdekhffgueenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppedtrddtrddtrddtpdefjedrheelrddugedvrddutdehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpqdhouhhtpdhhvghlohepmhigphhlrghniedrmhgrihhlrdhovhhhrdhnvghtpdhinhgvtheptddrtddrtddrtddpmhgrihhlfhhrohhmpegtohhnthgrtghtsehsihhmohhnsggvrhhnrghrugdrvghupdhrtghpthhtoheptggrsghosehtiihirdhorhhg
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/vspoS_zTe8tnwNzeTnLPUW4gUJc>
Subject: Re: [core] block1 size negotiation with 4.13 Request Entity Too Large
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jul 2020 12:43:22 -0000
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
- [core] block1 size negotiation with 4.13 Request … Simon Bernard
- Re: [core] block1 size negotiation with 4.13 Requ… Achim Kraus
- [core] Fwd: Re: block1 size negotiation with 4.13… Achim Kraus
- Re: [core] block1 size negotiation with 4.13 Requ… Carsten Bormann
- Re: [core] block1 size negotiation with 4.13 Requ… Simon Bernard
- Re: [core] block1 size negotiation with 4.13 Requ… Achim Kraus
- Re: [core] block1 size negotiation with 4.13 Requ… Carsten Bormann
- Re: [core] block1 size negotiation with 4.13 Requ… Simon Bernard
- Re: [core] block1 size negotiation with 4.13 Requ… Achim Kraus
- Re: [core] block1 size negotiation with 4.13 Requ… Achim Kraus
- Re: [core] block1 size negotiation with 4.13 Requ… supjps-ietf
- Re: [core] block1 size negotiation with 4.13 Requ… Carsten Bormann
- Re: [core] block1 size negotiation with 4.13 Requ… Achim Kraus
- Re: [core] block1 size negotiation with 4.13 Requ… Carsten Bormann