HTTP Media Type Structured Suffix
Extract the final structured subtype suffix after validating the complete Content-Type through the existing parser; no IANA registration claim.
Description
Extract the final structured subtype suffix after validating the complete Content-Type through the existing parser; no IANA registration claim.
A structured media-type suffix is the final plus-delimited part of a parsed subtype. It identifies spelling rather than validating content.
When to use this tool
Extract the final structured subtype suffix after validating the complete Content-Type through the existing parser; no IANA registration claim.
- Prepare the supplied contentType fields for this operation.
- Compare the complete example with the representation used by your own input before carrying the result into another step.
How to use the tool and how it works
- Enter contentType. Use the exact text syntax, units and index conventions explained below.
- Run the tool. If input validation fails, correct the supplied fields before interpreting any result.
- Read result.mediaType, result.structuredSuffix. Interpret false, null and empty lists using the distinctions below; they can be valid outputs.
Use the existing Content-Type parser on contentType, take its canonical mediaType, find the subtype's final plus and return the following nonempty text as structuredSuffix or null.1, 2
| Input field | Meaning and representation | Accepted input |
|---|---|---|
| contentType | content type. | Text; at most 8,192 UTF-16 code units, subject to the grammar above |
| Output field | Interpretation |
|---|---|
| result | Object containing the named outputs below. |
| result.mediaType | The media type value under the stated formula or text convention. |
| result.structuredSuffix | The structured suffix value under the stated formula or text convention. |
{
"input": {
"contentType": "application/problem+json"
},
"output": {
"result": {
"mediaType": "application/problem+json",
"structuredSuffix": "json"
}
}
}Limitations and assumptions
- No suffix registry or body-format conformance is checked. Parameters are parsed by the underlying tool but are not the suffix, and no content is fetched.
- Every declared top-level field is required and unexpected fields are rejected. Numeric inputs must be finite; ordinary text fields are bounded to 8,192 UTF-16 code units, with tighter operation-specific limits where stated.
- String lists have at most 128 entries of at most 128 code units; matrices have at most 128 rows and columns. Larger numeric lists and parsed JSON have separate bounded budgets. Nonfinite results and excessively large serialized outputs are rejected.
- Indexes are zero-based and spans have an exclusive end unless explicitly stated otherwise. A valid false, null or empty-list result is distinct from malformed input.
Alternative or Complementary methods
Use a complete protocol or URL parser when interpreting a whole message or address. Preserve raw spelling when required and distinguish HTTP token grammar, URL path normalization and form-style query decoding.
References
Similar or alternative tools
- HTTP Content Length Decimal Parser
Parse Content-Length as exact unsigned ASCII decimal text without unsafe numeric conversion, signs, whitespace or exponent syntax.
- HTTP Content Length List Consistency
Audit comma-combined Content-Length decimal members for exact numeric consistency after OWS trimming; does not accept empty members.