Specifying a different filename; Not storing the ContentDisposition header. #35

New issue

Closed

opened 2016-09-02 17:14:24 +12:00 by mikedilger · 1 comment

mikedilger commented

2016-09-02 17:14:24 +12:00

(Migrated from github.com)

Currently there are two places where name exists within the files array: (1) the first string in the pair, and (2) the name in the ContentDisposition header. filename OTOH is only in the ContentDisposition header (and thus more difficult to access for readers).

Additionally, when writing out a FormData, the filename for a FilePart is taken from the path of that part. But the consumer of the library might want to specify a different filename than the actual one on disk.

I suggest fixing these problems in the following way:

Store a filename in the FilePart (this change is required in mime-multipart)
Consider the first string in the pair the canonical name, and the FilePart.filename the canonical filename.
When reading, interpret and strip out the ContentDisposition header. When writing, ignore any ContentDisposition header and instead compose one from the canonical data.

Currently there are two places where `name` exists within the files array: (1) the first string in the pair, and (2) the `name` in the `ContentDisposition` header. `filename` OTOH is _only_ in the `ContentDisposition` header (and thus more difficult to access for readers). Additionally, when writing out a `FormData`, the filename for a `FilePart` is taken from the path of that part. But the consumer of the library might want to specify a different filename than the actual one on disk. I suggest fixing these problems in the following way: 1. Store a `filename` in the `FilePart` (this change is required in `mime-multipart`) 2. Consider the first string in the pair the canonical name, and the `FilePart.filename` the canonical filename. 3. When reading, interpret and strip out the ContentDisposition header. When writing, ignore any ContentDisposition header and instead compose one from the canonical data.

mikedilger commented

2023-09-30 06:55:43 +13:00

(Migrated from github.com)

Closing to to archival status

This discussion has been locked. Commenting is limited to contributors.