Backend Checklist - Day 4: Anatomy of an HTTP request For years I assumed an HTTP request was some packed binary format that the browser and the server both knew how to decode. It's plain text. You could type it onto the socket by hand. Four parts go onto the wire: > Request line: the method, the path, the version > Headers: everything about the request that isn't the request itself > A blank line >Body: the actual data, and only some methods send one The blank line It looks like formatting. It's the only thing telling the server the headers have ended and the next bytes are payload. Nothing else marks that boundary. Content-Length The connection stays open after your request, so the server can't tell the body ended just because bytes stopped arriving. It reads exactly as many bytes as you declared, and not one more. Declare 25 and send 20, and it waits for five bytes that never come. Declare 25 and send 34, and those nine leftovers sit in the buffer and get read as the start of the next request. In Django this isn't abstract. DATA_UPLOAD_MAX_MEMORY_SIZE reads the Content-Length header directly and raises RequestDataTooBig before your view ever runs. Default is 2.5MB. curl -v prints the whole thing if you want to see it.