- From: Roberto Polli <roberto@teamdigitale.governo.it>
- Date: Tue, 15 Sep 2020 11:31:36 +0200
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
Hi all, I just noted I replied to Amos without CC the ML. Il giorno mar 15 set 2020 alle ore 05:49 Julian Reschke <julian.reschke@gmx.de> ha scritto: > Am 14.09.2020 um 23:32 schrieb Amos Jeffries: > > On 14/09/20 8:06 pm, Julian Reschke wrote: > >> Am 12.09.2020 um 03:13 schrieb Amos Jeffries: > >>> ... > >> I don't think that negotiation is stricly needed. +1 > >>> If negotiation is needed, then are we perhapse better off instead > >>> negotiating the fact that GET payload is usable? In my experience, servers use GET when they don't want to process payload and manage the burdens of receiving it. Sometimes they interpret GET with payload as potentially harmful requests and act accordingly (eg. blocking/dropping the request). imho using a different method makes it easy to isolate cacheable and constrained GET requests from other - more complex - endpoints accepting a payload body and which are subject to more complex security concerns. > > I think this is the only way GET-with-payload would actually work > > reliably while those known issues exist. Origin that support it sending > > the header and middleware that don't dropping the header. So clients > > receiving the header know they can use GET payloads. > > So we would need to modify intermediaries and software components. I > believe this is a non-starter. +1 My2¢, R. -- Roberto Polli API Expert M. +39 3406522736 MID DIPARTIMENTO PER LA TRASFORMAZIONE DIGITALE Presidenza del Consiglio dei Ministri - Ministro per l'innovazione tecnologica e la digitalizzazione https://innovazione.gov.it/ Il Dipartimento per la Trasformazione Digitale, salvo eccezioni, comunica con le altre Amministrazioni via posta elettronica ordinaria e non posta elettronica certificata, in conformità a quanto previsto dall’art.47 del Codice dell’Amministrazione Digitale.
Received on Tuesday, 15 September 2020 09:32:02 UTC