Conversation
Based on Andreu's work at https://github.com/andreubotella/multipart-form-data with mostly editorial changes and some corrections. WPT coverage at fetch/api/response/response-form-data.html
| <p>To <dfn export for="multipart/form-data/boundary">generate</dfn> a | ||
| <a for="multipart/form-data" lt="boundary"><code>multipart/form-data</code> boundary</a>, return an | ||
| <a>implementation-defined</a> <a for=/>byte sequence</a> which fulfills the conditions for | ||
| boundaries, such that part of it is randomly generated, with a minimum entropy of 95 bits. |
There was a problem hiding this comment.
This was based on my analysis which IIRC concluded that Chromium/WebKit's boundary had exactly 95 bits of entropy, and that Gecko's was probably close to but less than 96 bits. But I see that at least Gecko has changed its boundary string generation now, and I'm not sure where it stands.
Do we want to spec something here that aligns with current implementations, or do we want to change this to some round number that makes sense (e.g. 32 * 3 = 96 bits would be easy to implement), and make implementations match?
| <ol> | ||
| <li><p>If <var>position</var> + 2 points to the end of <var>input</var>, or | ||
| <var>position</var> + 2 points to a sequence of bytes starting with 0x0D 0x0A (CR LF), then | ||
| return <var>entryList</var>. |
There was a problem hiding this comment.
According RFC, there could be some spaces between -- and CRLF, not sure what UAs are doing though.
Also, I am not sure what happens with UAs if there are non whitespace characters after --. Maybe entryList is returned instead of a failure.
3 participants
Based on Andreu's work at https://github.com/andreubotella/multipart-form-data with mostly editorial changes and some corrections.
WPT coverage at fetch/api/response/response-form-data.html
(See WHATWG Working Mode: Changes for more details.)
Preview | Diff