Consolidated Parameters Part for Multipart/Form-Data
draft-motiwala-consolidated-multipart-params-00

Internet-Draft Y. Motiwala
Intended status: Informational mesibo
Expires: 3 June 2026 December 2025
 Consolidated Parameters Part for Multipart/Form-Data
 draft-motiwala-consolidated-multipart-params-00
Abstract
 This document describes a deployment pattern for reducing overhead in
 multipart/form-data requests that include both file uploads and
 numerous text parameters. The approach consolidates multiple text
 fields into one or more application/x-www-form-urlencoded parts
 inside the multipart body.
 This technique requires no changes to existing HTTP, MIME, or form
 specifications and is fully compatible with RFC 7578. It uses only
 existing, standardized Content-Type values in their already-defined
 manner, making it immediately deployable with current infrastructure.
 The pattern guarantees backward compatibility: servers that don't recognize
 it still receive all parameters as standard form data. RFC 7578
 defines multipart/form-data but does not specify optimization
 strategies; this document fills that gap.
 This document records the pattern, processing rules, and deployment
 considerations, and reports implementation experience from production
 systems processing millions of uploads daily.
Status of This Memo
 This Internet-Draft is submitted in full conformance with the
 provisions of BCP 78 and BCP 79.
 Internet-Drafts are working documents of the Internet Engineering
 Task Force (IETF). Note that other groups may also distribute
 working documents as Internet-Drafts. The list of current Internet-
 Drafts is at https://datatracker.ietf.org/drafts/current/.
 Internet-Drafts are draft documents valid for a maximum of six
 months and may be updated, replaced, or obsoleted by other documents
 at any time. It is inappropriate to use Internet-Drafts as reference
 material or to cite them other than as "work in progress."
 This Internet-Draft will expire on 3 June 2026.
Copyright Notice
 Copyright (c) 2025 IETF Trust and the persons identified as the
 document authors. All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (https://trustee.ietf.org/license-info) in effect on the date of
 publication of this document. Please review these documents
 carefully, as they describe your rights and restrictions with
 respect to this document.
Table of Contents
 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
 1.3. Relationship to Existing Standards . . . . . . . . . . . 5
 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 6
 2.1. Current Inefficiency . . . . . . . . . . . . . . . . . . 6
 2.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 7
 2.3. Standards Gap . . . . . . . . . . . . . . . . . . . . . . 8
 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 9
 3.1. Format Definition . . . . . . . . . . . . . . . . . . . . 9
 3.2. Standards Compliance . . . . . . . . . . . . . . . . . . 10
 3.3. Requirements . . . . . . . . . . . . . . . . . . . . . . 11
 3.3.1. Client Requirements . . . . . . . . . . . . . . . . . 11
 3.3.2. Server Requirements . . . . . . . . . . . . . . . . . 12
 3.4. Field Name Conflicts . . . . . . . . . . . . . . . . . . 12
 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13
 4.1. Standard Multipart (Before) . . . . . . . . . . . . . . . 13
 4.2. Consolidated Parameters (After) . . . . . . . . . . . . . 14
 4.3. Multiple Files with Parameters . . . . . . . . . . . . . 15
 5. Implementation Experience . . . . . . . . . . . . . . . . . . 16
 5.1. Efficiency Measurements . . . . . . . . . . . . . . . . . 16
 5.2. Compatibility Validation . . . . . . . . . . . . . . . . 16
 5.3. Backward Compatibility . . . . . . . . . . . . . . . . . 17
 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
 8.1. Normative References . . . . . . . . . . . . . . . . . . 18
 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19
 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction
 HTML forms with file upload capabilities must use the
 multipart/form-data encoding type [RFC7578]. This encoding wraps
 each form field, including simple text fields, in a MIME part with
 headers and boundary delimiters. For forms containing numerous text
 parameters alongside file uploads, this creates significant overhead.
 Consider a file upload form with 15 text fields (user_id,
 session_token, file_type, permissions, metadata fields, etc.) and
 one file. Using standard multipart/form-data, each text field
 requires approximately 100 bytes of overhead to transmit perhaps
 20 bytes of actual data, representing a 4-6x inflation factor
 for parameter transmission.
 RFC 7578 [RFC7578] defines multipart/form-data but does not specify
 how implementations should balance efficiency with compatibility.
 This has led to divergent practices: browsers generate one part per
 field, some APIs embed JSON metadata, and custom implementations use
 various ad-hoc approaches.
 Browsers generate one MIME part per form field because the HTML form
 submission algorithm requires each form control to become one entry
 in the form data set, and each entry becomes one multipart part. This
 behavior originates from the HTML Standard, not from multipart/form-data
 itself. Nothing in HTTP, MIME multipart semantics, or RFC 7578 prevents
 other user agents from using more efficient encoding strategies that
 result in fewer multipart parts and reduced overhead.
 This document describes Consolidated Parameters, a general-purpose
 multipart/form-data encoding pattern in which multiple text
 parameters are combined into one or more application/x-www-form-
 urlencoded parts inside the multipart body. The technique requires no
 extensions to HTTP, no additions to MIME, and no deviations from
 RFC 7578. It is fully standards-compliant and may be used by any HTTP
 user agent, reducing parameter transmission overhead while remaining
 fully backward compatible with existing parsers.
 The pattern applies to all HTTP clients, and any client may
 adopt it while remaining fully compliant with existing standards.
 The pattern guarantees backward compatibility because servers that 
 do not recognize it still receive all parameters as standard 
 form-data fields, which can be manually parsed using existing form 
 handling logic. This enables safe deployment without requiring 
 coordination between clients and servers.
 This approach has been deployed in production systems processing
 millions of uploads daily, demonstrating its effectiveness and
 compatibility in real-world use.
1.1. Requirements Language
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
 "OPTIONAL" in this document are to be interpreted as described in
 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
 uppercase, as shown here.
 As an Informational specification, the use of normative language
 describes implementation recommendations for interoperability rather
 than mandatory protocol requirements.
1.2. Terminology
 This document uses the following terms:
 Standard Multipart: A multipart/form-data request where each form
 field is encoded as a separate MIME part, as traditionally
 generated by web browsers.
 Consolidated Parameters: An approach where multiple text parameters
 are encoded together in a single multipart part using
 application/x-www-form-urlencoded format. This term is used purely
 as a descriptive label and has no normative meaning.
 Parameters Part: A MIME part within multipart/form-data that has
 Content-Type: application/x-www-form-urlencoded and contains
 multiple name=value pairs in URL-encoded format.
1.3. Relationship to Existing Standards
 This document does not modify, extend, or add anything to existing
 standards. It describes an application-level pattern using only
 existing, standardized Content-Type values:
 o multipart/form-data as defined in [RFC7578]
 o application/x-www-form-urlencoded as defined in [HTML5]
 Both specifications already permit arbitrary Content-Type values in
 multipart parts. This document simply describes consolidating
 parameters into a single part rather than using separate parts for
 each parameter - a choice already available within current
 specifications.
 The inefficiency of one-part-per-field encoding arises from the HTML
 form submission algorithm, which currently requires browsers to generate
 one multipart part per form control. However, this is a requirement of
 the HTML Standard, not of HTTP, MIME multipart semantics, or RFC 7578.
 Nothing in these protocol specifications mandates one MIME part per
 field. As a result, HTTP clients have full flexibility to use more
 efficient encodings while remaining fully compatible with existing
 parsers. Future browser implementations may adopt this optimization
 if the HTML Standard is updated to permit more efficient multipart
 encoding strategies.
 Since this pattern uses only existing, standardized content types
 within their defined semantics, all standard HTTP and multipart
 processing rules continue to apply. Security validation, duplicate
 field handling, streaming uploads, chunked transfer encoding, and
 other standard behaviors remain unchanged. No special-case handling
 is required beyond what is already defined in the referenced
 specifications.
2. Motivation
2.1. Current Inefficiency
 The multipart/form-data format transmits each form field as an
 individual MIME part with its own Content-Disposition header,
 optional Content-Type, and boundary delimiters. For small forms
 this overhead is negligible, but it becomes significant when many
 short text parameters accompany one or more files.
 For example, transmitting the value "12345" for a user_id field
 requires:
 ------WebKitFormBoundary7MA4YWxkTrZu0gW
 Content-Disposition: form-data; name="user_id"
 12345
 This represents approximately 105 bytes total to transmit 12 bytes
 of data (field name "user_id" plus value "12345").
 Each text field adds significant structural overhead. When many
 short text parameters accompany files, cumulative overhead becomes
 disproportionately large relative to the actual content. This
 increases bandwidth and CPU cost when forms include many parameters
 and upload volume is high.
 Per-field overhead in a typical multipart form:
 o Boundary delimiter: ~40 bytes (--boundary + CRLF)
 o Content-Disposition header: ~45-60 bytes
 o Empty line separator: 2 bytes (CRLF)
 o Trailing CRLF: 2 bytes
 o Total: ~90-105 bytes per field
 o Overhead-to-payload ratio: approximately 9:1
 (Note: These calculations assume HTTP transport where binary data is
 transmitted directly. Email contexts requiring base64 encoding would
 have additional overhead not shown here.)
 For a form with 15 such fields (each ~20 bytes of data):
 o Standard multipart: ~1575 bytes overhead + 300 bytes data = 1875
 o URL-encoded consolidated: ~105 bytes overhead + 300 bytes = 405
 o Savings: 1470 bytes (78% reduction in total request size)
 The problem is further amplified in deployments that process large
 volumes of uploads. Across millions of requests per day, excessive
 multipart overhead directly increases operational bandwidth, and
 processing costs. A social platform processing 100 million photo
 uploads per day with 15 metadata fields per upload saves multiple 
 terabytes (TB) monthly in bandwidth costs alone, not including 
 reduced latency benefits for users on mobile networks.
2.2. Applicability
 This approach applies universally to any HTTP-based file upload that
 includes multiple text parameters. Typical examples include:
 o User-generated content (photos, videos, documents) with metadata
 (user ID, timestamps, privacy settings, descriptions)
 o Application data synchronization with context (device ID, sync
 tokens, version information)
 o API requests combining binary payloads with authentication,
 configuration, or processing parameters
 The benefit scales with the number of text parameters. Forms with 5
 or more parameters show measurable improvement; forms with 10+
 parameters achieve significant bandwidth reduction.
 Virtually all modern applications perform file uploads with metadata,
 making this approach widely applicable across web, mobile, IoT, and
 API contexts. The specific application domain (social media,
 e-commerce, healthcare, etc.) does not affect applicability or
 benefit.
2.3. Standards Gap
 RFC 7578 [RFC7578] defines multipart/form-data but does not specify
 efficient encoding strategies for forms with numerous text parameters.
 The specification describes the traditional one-part-per-field
 approach used by browsers but remains silent on efficiency
 considerations.
 This omission has resulted in implementation fragmentation. Browsers
 follow the HTML form submission algorithm (one part per field), while
 API implementations have adopted various approaches: some embed all
 parameters in JSON objects, others use custom encodings, and many
 simply accept the inefficiency of standard multipart encoding.
 This document addresses this gap by providing a standardized
 efficient encoding pattern that:
 o Uses only standardized Content-Type values (multipart/form-data 
 and application/x-www-form-urlencoded)
 o Maintains full backward compatibility with RFC 7578 parsers
 o Provides measurable efficiency improvements (Section 2.1)
 o Has been validated in production deployments (Section 5)
3. Specification
3.1. Format Definition
 An optimized multipart/form-data request MAY include one or more
 parts with Content-Type: application/x-www-form-urlencoded. Such
 parts consolidate multiple text parameters using the URL-encoded
 format defined in [HTML5] and [RFC3986].
 Example structure:
 POST /upload HTTP/1.1
 Host: api.example.com
 Content-Type: multipart/form-data; boundary=----Boundary123
 ------Boundary123
 Content-Disposition: form-data; name="params"
 Content-Type: application/x-www-form-urlencoded
 user_id=12345&session=abc&type=document&permissions=read
 ------Boundary123
 Content-Disposition: form-data; name="file"; filename="doc.pdf"
 Content-Type: application/pdf
 [binary PDF data]
 ------Boundary123--
 The part name (e.g., "params") is arbitrary and has no special
 meaning. Servers MUST identify the parameters part by its Content-
 Type header, not by its name.
 URL-encoded content MUST follow the application/x-www-form-
 urlencoded specification:
 o Field names and values are URL-encoded per [RFC3986]
 o Name=value pairs are separated by "&" (ampersand)
 The parameters part MAY appear at any position within the multipart
 sequence. However, placing it first is RECOMMENDED for efficient
 server processing, as authentication tokens and request metadata can
 be validated before processing file data. This is particularly
 beneficial for streaming uploads, where early validation can reject
 unauthorized requests before receiving large file payloads.
3.2. Standards Compliance
 This approach operates entirely within existing specifications:
 RFC 7578 [RFC7578] (multipart/form-data):
 Defines multipart/form-data and specifies that each part has an
 optional Content-Type (Section 4.4). It does not prescribe which
 Content-Type values are permitted, nor does it mandate that each
 form field must be a separate part.
 HTML5 [HTML5] (application/x-www-form-urlencoded):
 Defines the URL-encoded format for form data. This document uses
 this format within a multipart part rather than as the entire
 request body.
 RFC 2046 [RFC2046] (MIME multipart):
 The foundation for multipart formats. Section 5.1 establishes that
 parts can have any Content-Type.
3.3. Requirements
3.3.1. Client Requirements
 Clients MUST properly URL-encode all parameter names and values in
 consolidated parameters according to [RFC3986].
 Clients may send consolidated parameters in all requests or only when
 servers support them. Both approaches provide the same compatibility
 guarantees:
 - Always: Send consolidated parameters in all requests. Even servers
 that don't recognize consolidated parameters receive all data as a
 single URL-encoded field, which can be manually parsed using
 existing form parsing logic, ensuring backward compatibility.
 - Conditionally: Detect server support through implementation-
 specific means (API documentation, configuration, version
 negotiation) and send consolidated parameters only when supported.
 Clients MAY omit the consolidated parameters part entirely if there
 are no text fields to send. A multipart request containing only file
 parts is valid and requires no special handling.
3.3.2. Server Requirements
 Servers processing multipart requests with consolidated parameters:
 1. MUST parse the multipart/form-data structure according to
 [RFC7578] without modification.
 2. When encountering a part with Content-Type:
 application/x-www-form-urlencoded, MUST parse that part's body
 using URL-decoding rules.
 3. MUST extract name=value pairs from the URL-encoded part and make
 them available to the application as form parameters.
 4. MUST process other parts (files, other content types) using
 standard multipart parsing.
 Example server-side processing logic:
 for (part in multipartRequest.parts) {
 if (part.contentType == "application/x-www-form-urlencoded") {
 params.merge(urlDecode(part.body));
 } else {
 // Existing processing for files and other parts
 processStandardPart(part);
 }
 }
 Graceful Degradation:
 Servers that do not recognize this optimization will treat the URL-
 encoded part as a single text field, which provides graceful
 degradation. The URL-encoded content is preserved as the field value
 and can be manually parsed if needed.
3.4. Field Name Conflicts
 The handling of duplicate field names in multipart/form-data is
 already defined by RFC 7578 and existing server implementations. This
 pattern does not change how duplicate field names are handled; servers
 apply their existing precedence rules.
 Servers typically handle duplicates using last-wins semantics, first-
 wins semantics, or by collecting all values into an array. The same
 rules apply here. Clients SHOULD avoid sending duplicate field names
 across parts to prevent ambiguity.
4. Examples
4.1. Standard Multipart (Before)
 Traditional browser-generated multipart for a file upload with
 metadata:
 POST /api/upload HTTP/1.1
 Host: api.example.com
 Content-Type: multipart/form-data; boundary=----WebKitBoundary
 ------WebKitBoundary
 Content-Disposition: form-data; name="user_id"
 12345
 ------WebKitBoundary
 Content-Disposition: form-data; name="session_token"
 abc123xyz789
 ------WebKitBoundary
 Content-Disposition: form-data; name="file_type"
 document
 ------WebKitBoundary
 Content-Disposition: form-data; name="permissions"
 read
 ------WebKitBoundary
 Content-Disposition: form-data; name="file"; filename="report.pdf"
 Content-Type: application/pdf
 [binary PDF data - 50KB]
 ------WebKitBoundary--
 Size analysis:
 o Parameter overhead: ~400 bytes
 o Parameter data: ~50 bytes
 o File overhead: ~120 bytes
 o File data: ~50,000 bytes
 o Total: ~50,570 bytes
4.2. Consolidated Parameters (After)
 The same upload using consolidated parameters:
 POST /api/upload HTTP/1.1
 Host: api.example.com
 Content-Type: multipart/form-data; boundary=----WebKitBoundary
 ------WebKitBoundary
 Content-Disposition: form-data; name="params"
 Content-Type: application/x-www-form-urlencoded
 user_id=12345&session_token=abc123xyz789&file_type=document&permissions=read
 ------WebKitBoundary
 Content-Disposition: form-data; name="file"; filename="report.pdf"
 Content-Type: application/pdf
 [binary PDF data - 50KB]
 ------WebKitBoundary--
 Size analysis:
 o Parameter overhead: ~120 bytes (one part)
 o Parameter data: ~85 bytes (includes "&" separators)
 o File overhead: ~120 bytes
 o File data: ~50,000 bytes
 o Total: ~50,325 bytes
 Savings: 245 bytes (0.48% of total, but 61% of parameter overhead)
 The total savings are small when files are large, but the reduction in
 parameter overhead is substantial. For forms with more parameters or
 smaller files, the percentage savings increases substantially. For a
 5KB file with 20 parameters, savings can exceed 15% of total request size.
4.3. Multiple Files with Parameters
 Uploading multiple files with shared metadata:
 POST /api/batch-upload HTTP/1.1
 Host: api.example.com
 Content-Type: multipart/form-data; boundary=----Boundary
 ------Boundary
 Content-Disposition: form-data; name="params"
 Content-Type: application/x-www-form-urlencoded
 user_id=12345&batch_id=B789&timestamp=1234567890&location=office
 ------Boundary
 Content-Disposition: form-data; name="file1"; filename="scan1.jpg"
 Content-Type: image/jpeg
 [JPEG data]
 ------Boundary
 Content-Disposition: form-data; name="file2"; filename="scan2.jpg"
 Content-Type: image/jpeg
 [JPEG data]
 ------Boundary
 Content-Disposition: form-data; name="file3"; filename="scan3.jpg"
 Content-Type: image/jpeg
 [JPEG data]
 ------Boundary--
 This pattern is particularly efficient when the same metadata applies
 to multiple files, avoiding repetition across parts.
5. Implementation Experience
5.1. Efficiency Measurements
 Production deployment shows this pattern reduces parameter
 transmission overhead by 45-60%. For forms with 10+ text parameters,
 total request size decreases by 8-15%.
 No performance degradation was observed in server parsing or client
 encoding. At scale, the approach has saved terabytes (TB) of bandwidth
 monthly across millions of daily uploads in chat and messaging
 applications.
5.2. Compatibility Validation
 Testing confirms standard multipart parsers correctly handle
 consolidated parameter parts as single text fields containing URL-
 encoded data, validating the graceful degradation property.
5.3. Backward Compatibility
 Production testing confirms this consolidation does not introduce
 breakage: all tested multipart parsers correctly process consolidated
 parameter parts as single text fields containing URL-encoded data.
 Since servers already handle URL-encoded parameters (from standard
 HTML forms or application/x-www-form-urlencoded requests), they can
 extract individual parameters from the consolidated field using
 existing parsing logic. No server modifications are required to
 maintain functionality; only optimized servers need additional logic
 to automatically extract parameters.
6. Security Considerations
 Consolidated parameters do not introduce new security risks beyond
 those already present in the underlying formats. Parameter-handling
 risks remain identical to those of standard application/x-www-form-
 urlencoded encoding, and the multipart encapsulation risks remain
 identical to those of standard multipart/form-data encoding.
 This pattern combines existing, well-understood formats. Implementers
 should consult the security considerations in the specifications for
 these formats:
 o RFC 7578 Section 8 - Security Considerations for
 multipart/form-data
 o HTML5 Section 4.10.22.6 - Security Considerations for
 application/x-www-form-urlencoded
 o RFC 3986 Section 7 - Security Considerations for URL encoding
 Servers should apply the same validation, size limits, and
 sanitization to consolidated parameters as they would to standard
 form fields. The security model remains unchanged: parameters arrive
 in a different encoding but do not change the threat model or the
 required security controls.
7. IANA Considerations
 This document has no IANA actions. It does not define new media
 types, require registrations, or modify existing registries. The
 optimization uses existing, well-defined media types:
 o multipart/form-data [RFC7578]
 o application/x-www-form-urlencoded [HTML5]
8. References
8.1. Normative References
 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
 Requirement Levels", BCP 14, RFC 2119,
 DOI 10.17487/RFC2119, March 1997,
 <https://www.rfc-editor.org/info/rfc2119>.
 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
 Resource Identifier (URI): Generic Syntax", STD 66,
 RFC 3986, DOI 10.17487/RFC3986, January 2005,
 <https://www.rfc-editor.org/info/rfc3986>.
 [RFC7578] Masinter, L., "Returning Values from Forms:
 multipart/form-data", RFC 7578, DOI 10.17487/RFC7578,
 July 2015, <https://www.rfc-editor.org/info/rfc7578>.
 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
 [HTML5] WHATWG, "HTML Living Standard - Forms",
 <https://html.spec.whatwg.org/multipage/forms.html>.
 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
 Extensions (MIME) Part Two: Media Types", RFC 2046,
 DOI 10.17487/RFC2046, November 1996,
 <https://www.rfc-editor.org/info/rfc2046>.
Acknowledgments
 The author would like to thank the mesibo engineering team for
 implementing and testing this optimization in production
 environments.
Author's Address
 Yusuf Motiwala
 mesibo
 San Francisco, CA
 United States of America
 Email: yusuf@mesibo.com
 URI: https://mesibo.com/