(fyi this has nothing to do with request headers - only form-data entries headers in the body)
decoders (backends) could rely on content-length and let let x amount of bytes pass throught instead of scanning for a boundary separators.
decoding a form-data could be faster
decoders would know earlier how large a file upload is before you receive a hole file.
This could easily be added without any code changes on developers parts.
Last-Modified header could also be inherited/included from a File instance with the lastModified property.
I bet no decoders would even use, care or break anything if they saw this two extra entry headers.
I have already written to whatwg on github and suggested that this two extra per-entry headers gets added - if you want to get some more background context.
I think i could add them into this library without breaking anything.
...Would like to hear what someone else have to say about this. Should i include them?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This is not in the specification but i can see a value by adding a
Content-Length
header before every entry so it would look something like this(fyi this has nothing to do with request headers - only form-data entries headers in the body)
This could easily be added without any code changes on developers parts.
Last-Modified
header could also be inherited/included from a File instance with thelastModified
property.I bet no decoders would even use, care or break anything if they saw this two extra entry headers.
I have already written to whatwg on github and suggested that this two extra per-entry headers gets added - if you want to get some more background context.
I think i could add them into this library without breaking anything. ...Would like to hear what someone else have to say about this. Should i include them?