docs(body-limit): align enforcement order with implementation

- Describe Content-Length rejection for missing, negative, or over-limit
- Reorder How It Works to check declared size before wrapping the stream
- Restrict body wrapping to methods that allow a body

Author: NeaByteLab

docs/id/middleware/body-limit.md

@@ -6,7 +6,7 @@ description: "Batasi ukuran body request masuk untuk mencegah payload yang terla
 
 > **Referensi**: [RFC 7230 HTTP/1.1 Message Syntax and Routing](https://datatracker.ietf.org/doc/html/rfc7230#section-3.3.1)
 
-Middleware Body Limit memberlakukan ukuran maksimum body request. Ketika body ada, stream body selalu dibungkus dengan limiter sehingga ukurannya diberlakukan terlepas dari header, yang mencegah payload besar membebani server.
+Middleware Body Limit memberlakukan ukuran maksimum body request. Ketika body ada pada metode yang mengizinkannya, stream body dibungkus dengan limiter sehingga ukurannya diberlakukan saat byte tiba, bukan hanya dari header, yang mencegah payload besar membebani server.
 
 ## Penggunaan Dasar
 
@@ -71,11 +71,11 @@ limit: 10 * 1024 * 1024
 
 ## Cara Kerja
 
-Ketika request punya body, middleware membungkus stream body dengan limiter byte sehingga ukurannya diberlakukan saat body dibaca (bukan hanya lewat header):
+Ketika request bisa membawa body, middleware memeriksa ukuran yang dideklarasikan dulu, lalu membungkus stream body dengan limiter byte sehingga ukurannya diberlakukan saat body dibaca, bukan hanya dari header:
 
-1. **GET/HEAD atau tanpa body** - tidak ada yang dibungkus dan request lolos.
-2. **Body ada** - stream body dibungkus dengan limiter. Ketika klien mengirim byte lebih banyak dari `limit`, pembacaan berhenti dan middleware membalas dengan **413**.
-3. **Content-Length** - ketika ada tanpa `Transfer-Encoding` dan di atas `limit`, request ditolak sebelum body dibaca.
+1. **GET atau HEAD** - tidak ada yang dibungkus dan request lolos.
+2. **Content-Length** - ketika ada tanpa `Transfer-Encoding`, request ditolak sebelum body dibaca jika nilainya bukan angka, negatif, atau di atas `limit`.
+3. **Body ada** - pada metode yang mengizinkan body, stream dibungkus dengan limiter. Ketika klien mengirim byte lebih banyak dari `limit`, pembacaan berhenti dan middleware membalas dengan **413**.
 
 ### RFC 7230
 
@@ -109,4 +109,4 @@ await router.serve(8000)
 
 ## Penanganan Error
 
-Ketika batas terlampaui, middleware mengembalikan pesan `Request body exceeds <limit> bytes limit` dengan **status code 413**. `Content-Length` yang diketahui di atas batas ditolak sebelum body dibaca, sementara stream chunked atau yang terlalu besar ditolak begitu byte tambahan tiba. Untuk membentuk response itu, daftarkan satu handler dengan [`router.catch()`](/id/error-handling/object-details), atau andalkan [perilaku default](/id/error-handling/default-behavior).
+Ketika batas terlampaui, middleware gagal dengan status **413** dan pesan `Request body exceeds <limit> bytes limit`, baik saat `Content-Length` yang dideklarasikan memicunya sebelum body dibaca maupun saat stream yang terlalu besar memicunya begitu byte tambahan tiba. Kegagalan itu dialirkan ke [error handler terpusat](/id/error-handling/object-details) seperti error lain, jadi bentuk response di sana atau andalkan [perilaku default](/id/error-handling/default-behavior).

docs/middleware/body-limit.md

@@ -6,7 +6,7 @@ description: "Limit incoming request body size to guard against oversized payloa
 
 > **Reference**: [RFC 7230 HTTP/1.1 Message Syntax and Routing](https://datatracker.ietf.org/doc/html/rfc7230#section-3.3.1)
 
-Body Limit middleware enforces a maximum request body size. When a body is present, the body stream is always wrapped with a limiter so the size is enforced regardless of headers, which keeps large payloads from overwhelming the server.
+Body Limit middleware enforces a maximum request body size. When a body is present on a method that allows one, the body stream is wrapped with a limiter so the size is enforced as bytes arrive, not only from headers, which keeps large payloads from overwhelming the server.
 
 ## Basic Usage
 
@@ -71,11 +71,11 @@ limit: 10 * 1024 * 1024
 
 ## How It Works
 
-When a request has a body, the middleware wraps the body stream with a byte limiter so the size is enforced as the body is read (not only via headers):
+When a request can carry a body, the middleware checks the declared size first, then wraps the body stream with a byte limiter so the size is enforced as the body is read, not only from headers:
 
-1. **GET/HEAD or no body** - nothing is wrapped and the request passes through.
-2. **Body present** - the body stream is wrapped with the limiter. When the client sends more bytes than `limit`, reading stops and the middleware responds with **413**.
-3. **Content-Length** - when present without `Transfer-Encoding` and above `limit`, the request is rejected before the body is read.
+1. **GET or HEAD** - nothing is wrapped and the request passes through.
+2. **Content-Length** - when present without `Transfer-Encoding`, the request is rejected before the body is read if the value is missing a number, negative, or above `limit`.
+3. **Body present** - on a method that allows a body, the stream is wrapped with the limiter. When the client sends more bytes than `limit`, reading stops and the middleware responds with **413**.
 
 ### RFC 7230
 
@@ -109,4 +109,4 @@ await router.serve(8000)
 
 ## Error Handling
 
-When the limit is exceeded, the middleware returns message `Request body exceeds <limit> bytes limit` with **status code 413**. A known `Content-Length` above the limit is rejected before the body is read, while a chunked or oversized stream is rejected as soon as the extra bytes arrive. To shape that response, register a single handler with [`router.catch()`](/error-handling/object-details), or rely on the [default behavior](/error-handling/default-behavior).
+When the limit is exceeded, the middleware fails with status **413** and message `Request body exceeds <limit> bytes limit`, whether a declared `Content-Length` trips it before the body is read or an oversized stream trips it as the extra bytes arrive. That failure routes through the [central error handler](/error-handling/object-details) like any other, so shape the response there or rely on the [default behavior](/error-handling/default-behavior).