- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 3 Feb 2021 11:25:16 +0100
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: ietf-http-wg@w3.org
Am 03.02.2021 um 11:18 schrieb Poul-Henning Kamp: > -------- > Julian Reschke writes: >> Am 03.02.2021 um 10:59 schrieb Poul-Henning Kamp: >>> -------- >>> Julian Reschke writes: >>>> Am 03.02.2021 um 10:48 schrieb Poul-Henning Kamp: >>>>> -------- >>>>> Julian Reschke writes: >>>>> >>>>>> 1xx messages can not have a message body. >>>>> >>>>> The message body does not belong to the 142, it belongs to the trailer= >> . >>>> >>>> Trailers in HTTP/1.1 require chunked encoding, thus a message body. You >>>> can't send a message body absent a final status code message. >>> >>> This is not "Trailers in HTTP/1.1", so that is not relevant. >>> >>> This is a new HTTP extension which makes it possible to transmit a respo= >> nse with body and header parts swapped. >> >> I still don't get how you deploy it in HTTP/1.1. > > *Only* if a requestor lights whatever "bat-signal" we choose, can the responder send a 142, the chunked body and the headers, in that order. > > The "bat-signal" should be designed to not pass through intermediaries which do not understand its significance. (ie: hop-by-hop header, > mentioned in Connection:) Well. What you are doing here is an incompatible change of the HTTP/1.1 wire format (yes, via opt-in). I don't think it's a good idea to deviate from the wire format and still call the version "1.1" (or "1.x" for that matter). Furhermore I really do not get why a change in wire format is *needed*. As Martin said, we can mint a new final status code that indicates that more status information will be in trailer fields. Best regards, Julian
Received on Wednesday, 3 February 2021 10:25:32 UTC