In current 0.4.1 behaviour, fields fed in the order [1, 2, 3, 4, ..., N] will be serialized by mpart-async in the order [1, N, N-1, ..., 2].
APIs like Amazon S3 expect all "normal form elements" to come before the actual file content, or you get a 400 Bad Request, with a message like:
<?xml version=\"1.0\" encoding=\"UTF-8\"?>
<Error><Code>InvalidArgument</Code><Message>Bucket POST must contain a field named 'key'. If it is specified, please check the order of the fields.</Message><ArgumentName>key</ArgumentName><ArgumentValue></ArgumentValue><RequestId>***</RequestId><HostId>wYRa8ODkO/***/fpb8=</HostId></Error>
Ideally, I think mpart-async should serialize the fields in the order that they were given, or at least the ordering should somehow be fixed and documented.
Yep, this was mainly because internally the client uses a Vec and pops from it. I've pushed a fix as of 0.4.2 that uses a VecDeque instead and will order correctly.
In current 0.4.1 behaviour, fields fed in the order
[1, 2, 3, 4, ..., N]
will be serialized bympart-async
in the order[1, N, N-1, ..., 2]
.APIs like Amazon S3 expect all "normal form elements" to come before the actual file content, or you get a 400 Bad Request, with a message like:
Ideally, I think
mpart-async
should serialize the fields in the order that they were given, or at least the ordering should somehow be fixed and documented.