- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 15 Feb 2017 16:56:46 +1100
- To: Adrien de Croy <adrien@qbik.com>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Hi Adrien, Interesting conversation ;) My .02 - The number of bytes that the sender sends and the recipient receives might be different (e.g., network segments, prematurely closed connections, machine crashes). The fact that the recipient receives less bytes than Content-Length indicated doesn't make the sender any less conformant. A pathological sender might send *more* bytes than Content-Length indicates. In the strictest sense, this behaviour is conformant, because it doesn't violate a MUST, but it clearly violates the intent of the field, and harms interoperability. Unfortunately, this isn't theoretical. As Alex and others have said, Content-Length defines the message body, in the contexts where it's used. A recipient can try to handle errors gracefully (e.g., doing something useful with an incomplete representation, or treating bytes following it on the connection as part of the representation when there isn't another outstanding message). As per 2.5: > Unless noted otherwise, a recipient MAY attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms except when they have a direct impact on security, since different applications of the protocol require different error handling strategies. Cheers, > On 15 Feb 2017, at 7:49 am, Adrien de Croy <adrien@qbik.com> wrote: > > > The language in RFC 7230 section 3.3.2 is extremely non-commital about whether Content-Length needs to be correct or not. > > I'm currently having a dispute about this with someone who quoted these sections at me as being proof that you can use any value for C-L regardless of the body length. > > I think it could be a lot more forcefully written > > Or is the person correct and we don't need to have C-L match the body length? > > In this particular case the discussion is around request messages. > > Adrien -- Mark Nottingham https://www.mnot.net/
Received on Wednesday, 15 February 2017 05:57:22 UTC