Hacker News new | ask | show | jobs
by wizofaus 1145 days ago
Does HTTP/2 have support for parallel uploads? As an end-user if I happen to select 1 huge file first, followed by a bunch of tiny files, having to wait for the entire huge file to be streamed to the server before it even knows about any of the others seems less than ideal. It also seems odd there's no way to provide a hint to the server about individual file-sizes up-front (only Content-Length which is your upper bound for the total size of all files). I'm also curious how clients are expected to generate boundary strings and what is supposed to happen if the uploaded file is discovered to have an instance of the boundary string in it. Or are we just relying on that being sufficiently improbable not to worry about it (a la guid uniqueness...)?
2 comments

Yes, HTTP/2 requests run on separate streams and will interleave chunks. They still have some head of line blocking however, since the TCP stream will not allow reading from another stream while waiting for another stream’s chunk to retransmit (for that you need HTTP/3).
HTTP/1 requests (uploads in this case) are also separate to some degree (though there are fairly stringent limits on connections per domain iirc which HTTP/2 resolves via the mentioned streams/multiplexing of connections).

The problem they have specifically would be that in a single request (form post for example) those uploads will be linear.

Solution really boils down to paralellizing the upload, using protocols/standards like https://tus.io/ or S3-compatible APIs to push the data up then syncronize with a record/document on the server.

You can technically add a Content-Length header for each part. It's not forbidden by the RFC, but nor is it common. It caused problems (https://github.com/square/okhttp/issues/2138) for OkHttp, and they eventually removed it. Might be fine for internal-only use, though.

Boundaries are a lot like UUIDs, and rely on the same logic. When generating random data, once you have enough bits, the odds are against that sequence of bits ever having been generated before in the universe.

EDIT: Was looking at the obsolete RFC. The current version, RFC 7578, actually forbids all part headers other than "Content-Type, Content-Disposition, and (in limited circumstances) Content-Transfer-Encoding".