Parallel Appends for Resumable Uploads

1.1. Use Cases

The main motivation is large uploads over paths where a single connection cannot use the available bandwidth: video and audio, disk images and backups, and datasets or model files that often run to several gigabytes. Section 12.1 explains which parts of the gain come from parallel appends on one connection and which need several connections.¶

Uploads to AI services are a growing case. Users attach documents, recordings, and video for a model to analyze, and the model cannot start until the upload has finished, so upload time shows up directly as waiting time. For small files the gain from parallel appends is small, because connection setup and round trips dominate. For large inputs it can be significant.¶

The same trend affects organizations that inspect outbound uploads, including uploads to AI services, to keep sensitive data from leaving their networks. Their proxies have to handle more and larger uploads with limited memory, and must not let a file be committed before it has been checked. Section 11.3 describes how they can do that.¶

Mobile clients benefit as well. Their connections drop and change often, and with this extension only the missing ranges need to be sent again.¶

4.1. The Upload-Parallel Request Field

The Upload-Parallel request header field is a Boolean [RFC9651]. A client sends it with the value true in an upload creation request to ask for parallel mode:¶

Upload-Parallel: ?1

A client that sends Upload-Parallel with the value true MUST also send Upload-Length in the same request. Parallel mode requires the total length to be known before appends arrive out of order. A server that receives Upload-Parallel without Upload-Length MUST treat the upload as sequential.¶

A client MAY create the upload with an empty body: a POST carrying Upload-Parallel, Upload-Length, Upload-Complete set to false, and no content. The response gives the client the Location of the upload resource and the Upload-Limit field, so it knows the upload URI and the limits that apply, that is how many appends may be in flight, the reorder window, any alignment, and the commit mode, before it sends any content. All content is then sent in appends.¶

POST /files HTTP/1.1
Host: example.com
Upload-Parallel: ?1
Upload-Length: 12582912
Upload-Complete: ?0
Content-Length: 0

HTTP/1.1 201 Created
Location: /uploads/abc
Upload-Limit: max-parallel=3, reorder-window=6291456

This is RECOMMENDED when HTTP/1.1 is used, because [RESUMABLE] otherwise carries the upload URI in a 104 (Upload Resumption Supported) interim response, which some intermediaries do not forward (Section 12.2).¶

4.2. Upload-Limit Parameters

This document defines the following parameters for the Upload-Limit response field of [RESUMABLE]:¶

max-parallel:

An Integer. The maximum number of appends to this upload that may be in progress at the same time. A value of 1 in the upload creation response means the upload is sequential (Section 4.4). If the parameter is absent, this field places no limit on the number of appends; concurrency is then bounded only by the reorder window and by what the server accepts at the time (Section 10.2).¶

reorder-window:

An Integer. The reorder window W in bytes. If absent, the window is unlimited, that is, equal to the upload length.¶

append-alignment:

An Integer. The offset of every append, and the length of every append except the tail append, MUST be a multiple of this value. If absent, no alignment applies.¶

commit:

A Token, either "auto" or "explicit". See Section 7. If absent, the value is "auto".¶

A server that accepts parallel mode MUST include at least one of max-parallel with a value greater than 1, or reorder-window, in the Upload-Limit field of the upload creation response, and MUST include its current values of these parameters in every later Upload-Limit field it sends for the upload, including in offset retrieval responses. A server that cares only about how much out-of-order data it has to hold can send reorder-window alone; one that cares only about the number of concurrent requests can send max-parallel alone.¶

4.3. Tightening by Intermediaries

An intermediary MAY modify the Upload-Limit field in a response it forwards, but only in ways that make the limits stricter:¶

• it MAY lower max-parallel, or add it if absent;¶

• it MAY lower reorder-window, or add it if absent;¶

• it MAY replace append-alignment with a multiple of the current value, or add it if absent;¶

• it MAY change commit from "auto" to "explicit".¶

An intermediary MUST NOT raise max-parallel or reorder-window, remove any of these parameters, or change commit from "explicit" to "auto". Because each hop can only tighten the limits, the values a client receives are the strictest on the path.¶

Only the party that has to satisfy a limit can raise it. Replacing append-alignment with a multiple of its current value is a further restriction on the client, not a new permission, which is why an intermediary may do it. Raising max-parallel or reorder-window would commit the server to work it has not agreed to, so an intermediary cannot do that even though it could reassemble the data itself. An intermediary that takes over parallel mode on the client-facing hop (Section 11.2) is a different case: there it acts as the server, and it MAY advertise its own limits, including larger ones, because it services them itself.¶

An intermediary that tightens a limit MUST enforce the value it advertised. The server knows only its own limits, so it would accept an append that breaks a tighter one. The intermediary therefore rejects or delays such an append itself, in the same way a server does (Section 10.2, Section 12.1.2).¶

Changing commit from "auto" to "explicit" works with any server that implements this document, because such a server accepts an empty append as the tail append in either mode (Section 7). An intermediary that makes this change tracks which ranges the server has received and applies the explicit-commit rules toward the client: if the client sends the commit request while ranges are still missing, the intermediary responds with 409 (Conflict) and "incomplete-ranges" instead of forwarding it (Section 7.2).¶

4.4. Falling Back to Sequential Uploads

An upload is in parallel mode if, and only if, the client sent Upload-Parallel with the value true and the Upload-Limit field in the response to upload creation contains either max-parallel with a value greater than 1, or reorder-window without max-parallel. A max-parallel value of 1 in that response always means sequential, even when reorder-window is also present. In every other case, client and server MUST follow [RESUMABLE] without the changes in this document. This is the only rule that decides the mode; other sections refer to it.¶

The mode is fixed when the upload is created, but the limits can change during the upload. Any response for the upload resource, whether to an append or to offset retrieval, MAY carry a different Upload-Limit. Each Upload-Limit field carries the complete current values: a parameter that is absent from it has the default meaning given in Section 4.2, not its previous value. A server MAY raise or lower its own limits. An intermediary recomputes its values from each new value it receives from upstream and still only tightens it (Section 4.3). A client MUST apply the most recent values to appends it starts after receiving them, and a change never invalidates an append already in progress (Section 10.2). A later max-parallel of 1 limits the client to one append at a time but does not end parallel mode; Upload-Received and the other rules of this document still apply.¶

5.1. The Reorder Window

Let C be the contiguous offset, L the upload length, and W the reorder window. In parallel mode, an append that covers bytes [o, o + n), where n is the length of its content, is inside the window if and only if:¶

    o + n <= min(C + W, L)

A client MUST NOT start an append that is outside the window as computed from the most recent Upload-Offset it has received. Because C only grows, an append that was inside the window when it started stays inside it.¶

A window equal to L allows unrestricted parallelism. A window equal to the size of one append results in sequential behavior while still permitting a new append to start as soon as the previous one completes.¶

5.2. Append Requests

Appends in parallel mode use the PATCH method and the application/partial-upload media type, as defined in [RESUMABLE]. The Upload-Offset request field carries the offset o at which the content starts; the content length gives n.¶

In parallel mode, Upload-Offset in an append request is not required to equal the server's current offset. It is the start of the byte range the append writes. A client MUST send Content-Length on every append in parallel mode, so that a recipient knows the full range before the content arrives.¶

If max-parallel is present, a client MUST NOT have more than that many appends to the same upload in progress at once. An append is in progress from when its request starts until its response is received or the request is abandoned.¶

A client SHOULD include a Content-Digest field [RFC9530] on each append so that the server and intermediaries can verify each range on its own.¶

PATCH /uploads/abc HTTP/1.1
Host: example.com
Content-Type: application/partial-upload
Upload-Offset: 4194304
Upload-Complete: ?0
Content-Length: 2097152
Content-Digest: sha-256=:(base64-encoded SHA-256 of the content):

[2097152 bytes]

5.3. Overlapping and Repeated Ranges

An append may overlap ranges the server has already received, for example when a client retries an append whose response it did not receive. Retrying a range with identical content is always safe.¶

A server MAY discard overlapping bytes without comparing them. If a server detects that overlapping bytes differ from the stored bytes (using Content-Digest, say), it MUST reject the append with status 409 (Conflict) and the problem type "range-conflict" (Section 13).¶

Two appends in flight for the same range with identical content are not a conflict. The server treats the newer one as a retry of the older (see below), and the range is stored once. The problem type "range-conflict" applies only when overlapping bytes differ.¶

If a new append overlaps a range that is being written by an append still in progress, the server SHOULD terminate the older append before processing the new one. This applies the rule of Section 4.6 of [RESUMABLE] per byte range instead of per upload: the newer request is taken to be a retry of the older one. Bytes the older append stored before termination remain received.¶

5.4. Interrupted Appends

When an append is interrupted, the server MAY keep the bytes it received as a received range, as in [RESUMABLE]. In parallel mode, this can leave a gap after the kept bytes. The client learns about the gap through offset retrieval (Section 6) and re-sends only the missing bytes.¶

7.1. Automatic Commit

When commit is "auto", the tail append is normally the data append that ends at L. A client MUST set Upload-Complete to true on the append that ends at L and on no other append. A server that receives Upload-Complete set to true on an append that does not end at L MUST reject it with status 400 (Bad Request).¶

In either commit mode, a server MUST also accept an empty append at offset L carrying Upload-Complete set to true as the tail append, if it has not already received one. [RESUMABLE] already allows such an append to complete an upload whose content has all arrived; accepting it in automatic mode is what lets an intermediary change the commit mode (Section 4.3).¶

If gaps remain when the tail append has been received, the server responds to the tail append with 204 (No Content) and the current Upload-Offset and Upload-Received. The upload completes when the last gap is filled. The append that fills it receives the final response for the upload, as described in [RESUMABLE]. Other appends receive 204 (No Content).¶

7.2. Explicit Commit

When commit is "explicit", every data append, including the one that ends at L, carries Upload-Complete set to false. After the client has received successful responses for all ranges, it sends an append with empty content, Upload-Offset set to L, and Upload-Complete set to true. That empty append is the tail append and receives the final response.¶

If the server receives the tail append while gaps remain, it MUST reject it with status 409 (Conflict), the problem type "incomplete-ranges", and the Upload-Received field.¶

Explicit commit separates receiving the data from committing it. It lets a client check the whole representation, using Repr-Digest [RFC9530], before committing. It also keeps the tail append small, which helps intermediaries that hold it (Section 11.3.3).¶

10.1. Upload State

A server that supports parallel mode MUST track the received ranges of each upload in parallel mode, and update them atomically: a range is either fully recorded or not recorded at all. Offset retrieval responses MUST reflect every range recorded before the request was received.¶

When requests for one upload can reach different server instances, for example behind a load balancer, all instances MUST share a consistent view of the received ranges, or requests for an upload MUST be routed to a single instance.¶

10.2. Enforcing Limits

A server MUST reject an append that is outside the reorder window with status 409 (Conflict), the problem type "offset-outside-window", and the current Upload-Offset, unless it delays the append as described in Section 12.1.2.¶

A server MAY reject an append with status 429 (Too Many Requests), the problem type "too-many-parallel", and a Retry-After field when accepting it would exceed max-parallel or, if max-parallel is absent, the number of concurrent appends the server can currently handle.¶

A server MUST reject an append whose offset or length violates append-alignment with status 400 (Bad Request) and the problem type "misaligned-append".¶

A server MAY raise or lower its limits during an upload, for example as its load changes, and signals new values in its next responses (Section 4.4). It MUST NOT reject an append that was inside the limits it last advertised when the append started solely because the limits changed.¶

10.3. Storage and Visibility

A server MAY write ranges directly into a single sparse object or store them separately and join them on completion. The choice is not visible to clients.¶

Until an upload is complete, a server MUST NOT make its content available as the representation of any target resource, and MUST NOT fill gaps with placeholder bytes that could be mistaken for uploaded content. An upload that is cancelled or expires MUST be discarded without being committed.¶

If a Repr-Digest was provided, the server SHOULD verify it against the joined content before committing and MUST NOT commit on a mismatch.¶

10.4. Resource Management

The reorder window bounds how much out-of-order data a server has to buffer per upload. A server that buffers in memory SHOULD choose reorder-window and max-parallel according to its memory budget, and SHOULD also limit the number of concurrent uploads per client.¶

10.5. Expiry, Failure, and Loss of State

Uploads expire as described in [RESUMABLE], and a server SHOULD state its expiry through the max-age parameter of Upload-Limit so that clients and intermediaries can bound how long they keep state for an upload. An upload that expires or is cancelled MUST be discarded without being committed (Section 10.3).¶

Upload-Offset never decreases, and Upload-Received lists only ranges the server holds. A server that loses recorded ranges, for example when an instance without shared state restarts, therefore MUST NOT report a smaller contiguous offset or fewer ranges for that upload. It MUST instead fail subsequent requests for the upload resource with 404 (Not Found) or 410 (Gone), so that the client creates a new upload rather than completing one with missing bytes.¶

11.1. All Intermediaries

Appends in parallel mode are ordinary HTTP requests. An intermediary that does not implement this document forwards them without change, and parallel mode works through it.¶

An intermediary that implements this document:¶

• MAY tighten Upload-Limit as described in Section 4.3, and MUST NOT loosen it;¶

• MAY force sequential behavior by removing Upload-Parallel from an upload creation request or by setting max-parallel to 1 in the upload creation response (Section 4.4);¶

• MUST enforce any limit it tightens (Section 4.3);¶

• MUST NOT remove or alter Upload-Received, except as described in Section 11.3.4;¶

• when it balances load across servers, MUST meet the consistency requirement of Section 10.1, for example by routing all requests for an upload resource to the same server.¶

Responses to appends and to offset retrieval are not cacheable, as specified in [RESUMABLE]; this is unchanged.¶

11.2. Terminating Parallel Mode at an Intermediary

An intermediary MAY accept parallel mode from clients while forwarding the upload to the server sequentially, for example because the server does not support this extension or is reached over a different HTTP version. Such an intermediary acts as the server for parallel mode on the client-facing hop: it MUST meet the requirements of Section 10 for that hop, buffer out-of-order data within the window it advertises, and forward bytes upstream in order as the contiguous offset advances.¶

11.3. Inspecting Intermediaries

An inspecting intermediary examines upload content before it reaches, or is committed at, the server. Such intermediaries only see content where they already terminate TLS, usually under an enterprise policy. This document does not change that.¶

Upload-Inspection: state=scanning, scanned=7340032

12.1. HTTP/2 and HTTP/3

Over HTTP/2 [RFC9113] and HTTP/3 [RFC9114], each append is a request on its own stream, and several appends can share one connection. Parallel appends on one connection already remove the idle round trip that sequential appends spend waiting for each response, and a slow append no longer holds up the ranges after it. With HTTP/3, a lost packet also delays only the stream it belongs to; with HTTP/2 it delays every stream on the connection.¶

Parallel appends on one connection do not raise that connection's throughput limit, however. All streams on a connection share one congestion controller, whether the transport is TCP or QUIC, so on a path with a long round-trip time or packet loss a single connection can still use only part of the available capacity. Only additional connections, each with its own congestion controller, lift that limit. A client MAY therefore spread appends over more than one connection when a single connection does not use the available capacity, subject to Section 12.3. The total number of appends in progress still stays within max-parallel when it is present.¶

Client                           Recipient
  | HEADERS 1, Upload-Offset: 0       |  C = 0,
  | HEADERS 3, Upload-Offset: 2097152 |  window [0, 6 MiB)
  | HEADERS 5, Upload-Offset: 8388608 |
  |---------------------------------->|
  |      WINDOW_UPDATE streams 1, 3   |  stream 5 is outside
  |<----------------------------------|  the window: no
  | DATA streams 1, 3                 |  further credit
  |---------------------------------->|
  |                                   |  C reaches 4 MiB,
  |      WINDOW_UPDATE stream 5       |  window [4, 10 MiB)
  |<----------------------------------|
  | DATA stream 5                     |
  |---------------------------------->|

12.2. HTTP/1.1

Over HTTP/1.1 [RFC9112], parallel appends use separate connections, one append per connection at a time. The following rules apply:¶

• If max-parallel is present, a client MUST NOT use more connections for appends to one upload than that value. Browsers are additionally limited by their per-origin connection limits.¶

• HTTP/1.1 has no per-request flow control. A client MUST NOT start an append outside the window, and a recipient SHOULD reject such an append with 409 and "offset-outside-window" rather than delay it.¶

• HTTP/1.1 has no priorities. A client keeps the append at the contiguous offset in progress first and MAY replace it with a new request on another connection if it stalls (Section 9).¶

• Some intermediaries do not forward informational responses. A client MUST NOT depend on receiving 104 (Upload Resumption Supported) and SHOULD create the upload with an empty body, taking the upload resource and limits from the final response.¶

• A client MUST NOT pipeline requests.¶

• Appends in parallel mode carry Content-Length (Section 5.2) and therefore do not use chunked transfer coding.¶

• A client MAY send Expect: 100-continue, and MUST continue if no 100 (Continue) response arrives, as described in [RFC9110].¶

If the upload is not in parallel mode (Section 4.4), client and server use the sequential behavior of [RESUMABLE] unchanged.¶

12.3. Congestion Control and Fairness

An upload that uses several connections can take more than one connection's share of a bottleneck it shares with other traffic. Additional connections are meant for paths where a single connection is limited by round-trip time or loss, not for gaining a larger share of a congested link. Therefore:¶

• A client SHOULD start with one connection and open additional connections only while doing so increases the upload's throughput. It SHOULD stop adding connections when it does not.¶

• A client SHOULD NOT use more connections for one upload than it needs, and MUST stay within max-parallel when it is present.¶

• Servers and intermediaries can limit concurrency for an upload with max-parallel, and can reject excess appends with 429 (Too Many Requests) (Section 10.2).¶

• Each connection runs the congestion control specified for its transport. This document does not change congestion control.¶

Multipath extensions to QUIC, under development in the IETF, could offer a single connection with a separate congestion controller for each path. This document does not depend on them.¶

15.1. HTTP Field Names

IANA is asked to register the following fields in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" established by [RFC9110]:¶

15.2. Upload-Limit Parameters

[RESUMABLE] does not establish a registry for Upload-Limit parameters, so the parameters max-parallel, reorder-window, append-alignment, and commit are defined in Section 4.2 of this document without a registration. If such a registry is created, IANA is asked to add these four parameters to it, with a reference to Section 4.2.¶

15.3. HTTP Problem Types

IANA is asked to register the problem types listed in Table 2 in the "HTTP Problem Types" registry established by [RFC9457], each with a reference to Section 13 of this document.¶

16.1. Normative References

[RESUMABLE]

Kleidl, M., Zhang, G., and L. Pardue, "Resumable Uploads for HTTP", Work in Progress, Internet-Draft, draft-ietf-httpbis-resumable-upload-13, 6 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-resumable-upload-13>.

[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/rfc/rfc2119>.

[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/rfc/rfc8174>.

[RFC8470]

Thomson, M., Nottingham, M., and W. Tarreau, "Using Early Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 2018, <https://www.rfc-editor.org/rfc/rfc8470>.

[RFC9000]

Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/rfc/rfc9000>.

[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

[RFC9112]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112, June 2022, <https://www.rfc-editor.org/rfc/rfc9112>.

[RFC9113]

Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, DOI 10.17487/RFC9113, June 2022, <https://www.rfc-editor.org/rfc/rfc9113>.

[RFC9114]

Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, <https://www.rfc-editor.org/rfc/rfc9114>.

[RFC9218]

Oku, K. and L. Pardue, "Extensible Prioritization Scheme for HTTP", RFC 9218, DOI 10.17487/RFC9218, June 2022, <https://www.rfc-editor.org/rfc/rfc9218>.

[RFC9457]

Nottingham, M., Wilde, E., and S. Dalal, "Problem Details for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023, <https://www.rfc-editor.org/rfc/rfc9457>.

[RFC9530]

Polli, R. and L. Pardue, "Digest Fields", RFC 9530, DOI 10.17487/RFC9530, February 2024, <https://www.rfc-editor.org/rfc/rfc9530>.

[RFC9651]

Nottingham, M. and P. Kamp, "Structured Field Values for HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024, <https://www.rfc-editor.org/rfc/rfc9651>.

16.2. Informative References

[BYTERANGE]

Wright, A., "Byte Range PATCH", Work in Progress, Internet-Draft, draft-ietf-httpapi-patch-byterange-04, 6 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-patch-byterange-04>.

[TUS]

tus project, "tus resumable upload protocol, version 1.0.0", 25 March 2016, <https://tus.io/protocols/resumable-upload>.