W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2015

Re: [Technical Errata Reported] RFC7230 (4412)

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 15 Jul 2015 14:13:04 +0200
Cc: ietf-http-wg@w3.org
Message-Id: <A02BB1A8-BFB6-4B4E-8F84-4CEB319A1CC9@mnot.net>
To: Amos Jeffries <squid3@treenet.co.nz>
I'm reluctant to open the door for wordsmithing the specs for readability in errata; everyone tends to have an opinion, and few actually read the errata, which leads me to believe it's not a good use of WG time.

That said, if you want to make a concrete suggestion, go ahead (before and after).


> On 10 Jul 2015, at 11:15 am, Amos Jeffries <squid3@treenet.co.nz> wrote:
> CC'ing Mark to make sure this is on his radar.
> This same text seems to keep coming up as errata (this is the third time
> IIRC) and as below it can even catch some of us WG regulars who know
> what its about.
> To me it seem that the core issue is the words 'request' and 'response'
> being semi-hidden in the long descriptive text.
> I wonder if it is worth putting in an eratta to have the paragraph split
> into two simpler paragraphs starting with words like "For requests ..."
> and "For responses ..." ?
> This is after all two different sets of handling criteria for different
> message types. It makes a fair bit of sense to have them in different
> clauses as the rest of the documents text generally does for similar things.
> Amos
> On 10/07/2015 9:29 a.m., Willy Tarreau wrote:
>> On Thu, Jul 09, 2015 at 04:11:10PM -0500, Zhong Yu wrote:
>>> On Thu, Jul 9, 2015 at 3:43 PM, Willy Tarreau <w@1wt.eu> wrote:
>>>> On Thu, Jul 09, 2015 at 01:33:46PM -0500, Zhong Yu wrote:
>>>>> The spec does allow a response like
>>>>> HTTP/1.1 200 OK
>>>>> Content-Type: text/plain
>>>>> Transfer-Encoding: gzip
>>>>> Connection: close
>>>> No it does not allow it as chunked is not last. It's in 3.3.1 :
>>>>   If any transfer coding
>>>>   other than chunked is applied to a request payload body, the sender
>>>>   MUST apply chunked as the final transfer coding to ensure that the
>>>>   message is properly framed.
>>> This text talk about "REQUEST" only :) The next sentence talks about
>>> "RESPONSE" -
>> Hmm yes, good catch, sorry!
>>>> If any transfer coding other than chunked is applied to a response
>>> payload body, the sender MUST either apply chunked as the final transfer
>>> coding or terminate the message by closing the connection.
>>> Apparently, the text is prune to misreading.
>> Indeed, I didn't pay attention, I tend to consider that the rule
>> applies to both directions, though the strict control in haproxy
>> clearly is only for the request, just as specified.
>> So yes, the spec allows it and also specifies how to process it.
>> I doubt any server find it fun to play this game given that we
>> all know that connection-delimited bodies are prone to silent
>> truncation, but that doesn't mean no server does it.
>> Regards,
>> Willy

Mark Nottingham   https://www.mnot.net/
Received on Wednesday, 15 July 2015 12:14:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:45 UTC