Description
Stable descending explicit HTTP quality ordering with original indexes and zero-quality entries retained; not full Accept specificity negotiation.
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
Stable descending explicit HTTP quality ordering with original indexes and zero-quality entries retained; not full Accept specificity negotiation.
When to use this tool
Use this tool to sort supplied HTTP quality records from highest to lowest q, preserving input order for equal weights.
How to use the tool and how it works
- Enter qualitiesJson 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.qualities. Use the ordering, boundary rules and absence conditions described below.
Validate explicit token/q records, attach original indexes and sort by descending q with stable source-order ties.2
| Input field | Meaning and units | Accepted input |
|---|---|---|
| qualitiesJson | JSON array of {token, q} records; q is from 0 through 1 in thousandth steps. Token uses HTTP token syntax. | 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.
{
"qualitiesJson": [
{
"token": "a",
"q": 0
},
{
"token": "b",
"q": 0.5
},
{
"token": "c",
"q": 1
}
]
}| Output field | Interpretation |
|---|---|
| result | Object containing the named fields below. |
| result.qualities | Quality records sorted descending, with original indexes. |
{
"input": {
"qualitiesJson": "[{\"token\":\"a\",\"q\":0},{\"token\":\"b\",\"q\":0.5},{\"token\":\"c\",\"q\":1}]"
},
"output": {
"result": {
"qualities": [
{
"token": "c",
"q": 1,
"index": 2
},
{
"token": "b",
"q": 0.5,
"index": 1
},
{
"token": "a",
"q": 0,
"index": 0
}
]
}
}
}Limitations and assumptions
- Zero-quality records remain present; this is ordering rather than complete HTTP content negotiation.
- 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 Quality Stable Order — tool.io
Similar or alternative tools
- HTTP Header Occurrence Order Map
Map explicit field occurrences to stable canonical-name ordering and within-name ordinals without serializing or reordering a request.
- HTTP Header Occurrence Stable Merge
Append two explicit ordered HTTP field occurrence lists with source-side/index provenance, preserving Set-Cookie and all repeated values rather than comma combining.