Repository navigation
content-disposition is optional for multipart/related #175
Description
According https://tools.ietf.org/html/rfc2387#section-4 on multipart/related content-disposition header is optional.
Library only grab a file if content-disposition exists.
I think library should be able to handle files without this optional header and save it with a random (based on timestamp for example) filename.
Activity
dougwilson commentedon May 16, 2017
Pull requests welcome!
franher commentedon May 16, 2017
hello @dougwilson,
I'm figuring out how to distinguish between a field or a file. My initial point should be use the
Content-Typeto be sure we are facing a file. What do you think?dougwilson commentedon May 16, 2017
I'm not sure. I would expect it to distinguish them however the spec says.
dougwilson commentedon May 16, 2017
This is the spec this module is trying to adhere to: https://tools.ietf.org/html/rfc7578 and it states (in https://tools.ietf.org/html/rfc7578#section-4.2):
I haven't really looked at the one you linked to, but figured to state what this module is trying to do may help here.
franher commentedon May 16, 2017
The spec you mention is for
multipart/form-data.In talking about
multipart/related, that looking in the code could be supported https://github.com/pillarjs/multiparty/blob/master/index.js#L40for
multipart/related, content-disposition is optional.dougwilson commentedon May 16, 2017
Right, it is for multipart/form-data. The first line in the README is as follows:
I honestly had no idea this module allowed multipart/related. Seems weird because they seems to have different requirements in some areas. I don't know much about multipart/related so will defer to you on what changes need to be made in that regard, but they shouldn't break the multipart/form-data compliance of this module, at least.
dougwilson commentedon May 16, 2017
I just noticed this module seems to have zero tests for multipart/related. Perhaps we should just release a new major just removing that content-type? Or are the similar enough to support both? Can you help me understand multipart/related ? How does it related to multipart/form-data ; like what are the similarities and the differences.
If both are supported, that would help, since afaik there is just a single parsing code path, so I assume it is just parsing multipart/related as if it was multipart/form-data, so writing down what the differences are between the two will help understand what is broken today and how much of a different code path would need to be added.
franher commentedon May 16, 2017
of course, I want to keep the behaviour of this module for
multipart/form-data.When I faced the issue of looking for
multipart/relatedparsers, I couldn't find even a module supporting that.According
multipart/relatedspec, it's useful when the body parts are related between them.