5 ms·
About #1, FYI you should never trust the content-length of an HTTP request. It actually says that in one of the spec versions or another. The problem with writ
by mannyv 3y ago
About #1, FYI you should never trust the content-length of an HTTP request. It actually says that in one of the spec versions or another.
The problem with writing the length out at the beginning of the message is that you need to know the length before you write it out. For large objects that may cause memory issues/be problematic.
In many cases it works just fine. I doubt any protocol puts a "0" as the length for a dynamic length, but I can see a many-months long technical fight about that particular design decision.
- kentonv 3y ago> FYI you should never trust the content-length of an HTTP request. It actually says that in one of the spec versions or another. That's not quite right. When a Content-Length is present, it is always correct by definition (it is what determines the body size; there's no way for the body to be a different size). What you probably mean is that you shouldn't ever assume that a Content-Length is available, because an HTTP message can alternatively be encoded using Transfer-Encoding: chunked, in which case the length is not known upfront. That is true, but doesn't change my point: Either Content-Length or chunked transfer encoding serve to delimit the HTTP entity-body, which makes any other in-band delimiter redundant.