What is "Content-Disposition: file" ? #15

New issue

Closed

opened 2015-09-08 10:20:24 +12:00 by conradkleinespel · 4 comments

conradkleinespel commented

2015-09-08 10:20:24 +12:00

(Migrated from github.com)

Hi @mikedilger !

Thanks again for your library. It's quite nice 👍

I was reading the RFC on application/form-data and saw no mention of Content-Disposition: file, which your library does seem to parse. The RFC says everything has to be Content-Disposition: form-data.

But I did see a mention of Content-Disposition: file in an old HTML spec. Do you have any more information about that ?

Would love to know more, if you have the time 😃

Thanks,
Conrad

Hi @mikedilger ! Thanks again for your library. It's quite nice :+1: I was reading the RFC on application/form-data and saw no mention of `Content-Disposition: file`, which your library does seem to parse. The RFC says everything has to be `Content-Disposition: form-data`. But I did see a [mention of `Content-Disposition: file` in an old HTML spec](http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13.4.1). Do you have any more information about that ? Would love to know more, if you have the time :smiley: Thanks, Conrad

mikedilger commented

2015-09-08 10:37:21 +12:00

(Migrated from github.com)

Hi Conrad,

IETF RFC 2388 section 4.4 mentions the "file" disposition which may be used in the case of multiple files within a sub-part.

We tried to code the library to handle all the cases that might reasonably be expected to show up. In any of these cases:

If the filename parameter is set in a Content-Disposition of a subpart,
if the Content-Type header exists in a subpart,
if a Content-Disposition of a subpart is set to "file"

...then that part of the whole is interpreted as a File and we move to the CapturingFile state.

Hope that helps, and feel free to ask for more details if you need them. If you see anything that looks wrong, I certainly would like to know.

Thanks,
Mike

Hi Conrad, IETF RFC 2388 section 4.4 mentions the "file" disposition which may be used in the case of multiple files within a sub-part. We tried to code the library to handle all the cases that might reasonably be expected to show up. In any of these cases: - If the `filename` parameter is set in a `Content-Disposition` of a subpart, - if the `Content-Type` header exists in a subpart, - if a `Content-Disposition` of a subpart is set to "file" ...then that part of the whole is interpreted as a File and we move to the CapturingFile state. Hope that helps, and feel free to ask for more details if you need them. If you see anything that looks wrong, I certainly would like to know. Thanks, Mike

conradkleinespel commented

2015-09-08 10:43:31 +12:00

(Migrated from github.com)

Hi Mike,

Thanks for the explanations 👍

I agree with you that this all makes a lot of sense.

I wonder why the new RFC 7578, which obsoletes 2388, does not mention the Content-Disposition: file. That sounds like a breaking change in the RFC. Or maybe I missed the part about Content-Disposition: file there as well ?

Thanks again,
Conrad

Hi Mike, Thanks for the explanations :+1: I agree with you that this all makes a lot of sense. I wonder why the new [RFC 7578](https://tools.ietf.org/html/rfc7578), which obsoletes 2388, does not mention the `Content-Disposition: file`. That sounds like a breaking change in the RFC. Or maybe I missed the part about `Content-Disposition: file` there as well ? Thanks again, Conrad

mikedilger commented

2015-09-08 10:52:24 +12:00

(Migrated from github.com)

RFC 7578 part 4.3 deprecates the use of multipart/mixed within multipart/form-data. Clients certainly should not be producing such things any more. However, we like to be resilient; if some client uses it, we understand it.

I suppose the IETF should have deprecated it in two steps: step 1 - clients no longer writing requests this way, and step 2 - servers no longer need to recognize them. But that did not seem to happen.

RFC 7578 part 4.3 deprecates the use of `multipart/mixed` within `multipart/form-data`. Clients certainly should not be producing such things any more. However, we like to be resilient; if some client uses it, we understand it. I suppose the IETF should have deprecated it in two steps: step 1 - clients no longer writing requests this way, and step 2 - servers no longer need to recognize them. But that did not seem to happen.

conradkleinespel commented

2015-09-08 11:01:39 +12:00

(Migrated from github.com)

Great to hear you're being resilient :-)

Thanks for everything !

Edit: I had misunderstoof the obsoleted RFC before. I hadn't understood that Content-Disposition: file was only to be used in a subpart of multipart/mixed. This all makes a lot more sense now.

Great to hear you're being resilient :-) Thanks for everything ! Edit: I had misunderstoof the obsoleted RFC before. I hadn't understood that `Content-Disposition: file` was only to be used in a subpart of `multipart/mixed`. This all makes a lot more sense now.

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