Description
Budget HTTP/1 field section octets under literal name-colon-space-value-CRLF serialization plus final CRLF; Latin-1 octets, not HTTP/2 compression or UTF-8.
HTTP field names are case-insensitive, while values follow each field’s own grammar. Repeated occurrences sometimes form lists but cannot always be combined. Quoted values, optional spaces/tabs and quality weights need their own treatment; the tools here use explicit field records or a stated text subset.1
Budget HTTP/1 field section octets under literal name-colon-space-value-CRLF serialization plus final CRLF; Latin-1 octets, not HTTP/2 compression or UTF-8.
When to use this tool
Use this tool to budget HTTP/1 field section octets under literal name-colon-space-value-CRLF serialization plus final CRLF; Latin-1 octets, not HTTP/2 compression or UTF-8.
How to use the tool and how it works
- Enter headersJson using the field definitions below. For JSON text, serialize the explicit records in the shown shape.
- Run the operation. Correct input errors before interpreting an output.
- Read result.lines, result.total. Use the ordering, boundary rules and absence conditions described below.
For each single-byte-compatible header, count name + colon-space + value + CRLF. Sum those counts and add two bytes for the final blank line.2
| Input field | Meaning and units | Accepted input |
|---|---|---|
| headersJson | JSON text encoding array of {name: string, value: string}. Keep the record keys and value types shown in the decoded example below. | Text, at most 8,192 UTF-16 code units; the operation’s grammar also applies. |
These are the decoded structures used in the example’s JSON text fields. Supply the corresponding serialized JSON strings as input.
{
"headersJson": [
{
"name": "X-A",
"value": "one"
},
{
"name": "x-a",
"value": "two"
},
{
"name": "Set-Cookie",
"value": "a=1"
}
]
} | Output field | Interpretation |
|---|---|
| result | Object containing the named fields below. |
| result.lines | Per-line byte counts including colon-space and CRLF. |
| result.total | Field-block byte count including the final blank CRLF line. |
{
"input": {
"headersJson": "[{\"name\":\"X-A\",\"value\":\"one\"},{\"name\":\"x-a\",\"value\":\"two\"},{\"name\":\"Set-Cookie\",\"value\":\"a=1\"}]"
},
"output": {
"result": {
"lines": [
10,
10,
17
],
"total": 39
}
}
} Limitations and assumptions
- This estimates an HTTP/1-style field block only, not a start line, HTTP/2 compression or transport overhead.
- Explicit header records have name and value strings. Names must use token syntax; supported value code units are tab or 32–255 excluding DEL. Byte budgets use that single-byte representation, not UTF-8 or HTTP/2 compression.
- Every declared top-level input field is required and unexpected fields are rejected. Ordinary strings are limited to 8,192 UTF-16 code units and lists to 128 entries, with tighter operation-specific bounds where stated. JSON text has bounded nesting and node counts.
- Numeric outputs must be finite and no larger in absolute magnitude than the safe-integer limit; operations returning exact large integers use decimal text. Positions are zero-based and spans end exclusively unless the operation explicitly states a different convention.
Alternative or Complementary methods
Choose field-specific parsing and combination rules rather than applying one policy to every header. Preserve occurrence order and use a full HTTP implementation for message framing and protocol-level decisions.
References
-
RFC 9110: HTTP Semantics — RFC Editor
-
Tool behavior and example: HTTP Header Occurrence Byte Budget — tool.io
Similar or alternative tools
- HTTP Header Occurrence Case Collisions
Audit HTTP field-name spelling collisions separately from repeated identical spellings; validates token names and Latin-1 field-value octets.
- HTTP Header Occurrence Name Groups
Group all HTTP field occurrences under ASCII case-insensitive names while retaining raw ordered occurrences; no list combination or deduplication.