search

masinter / multipart-form-data

update to RFC 2388 definition of multipart/form-data
8 stars 6 forks source link

What's the holdup? #17

Open annevk opened 10 years ago

annevk commented 10 years ago

I ran some simple tests using http://software.hixie.ch/utilities/js/live-dom-viewer/ and http://software.hixie.ch/utilities/cgi/test-tools/echo and I'm wondering why this is taking so long.

This format seems pretty straightforward. As far as I can tell @dthaler is correct. The way things like name="..."'s value are encoded is not, it's just the bytes coming out of the encoder (which depends on the encoding of the <form>).

Text entries have no Content-Type header and the others do. multipart/mixed is not to be used.

All we need here is an algorithm that takes a set form entries and serializes them and an algorithm that does the reverse. Ideally soon as we need both of these algorithms in browsers due to service workers (a sort of proxy server).

I'm somewhat tempted to just inline these algorithms and define this format together with its API, just as we already did for application/x-www-form-urlencoded.

masinter commented 10 years ago

The holdup

0) no review of the actual March 2014 document that I'm aware of. @dthler's comments had been addressed.

1) I have no confidence that it is possible for to write anything here that will meet your goals. The experience with IRI/URL and [Encodings] has been negative.

2) implementations differ, and it's necessary to get implementors together to decide which behavior is 'normative' and which is 'implementor advice for compatibility with legacy content/browsers'. I call this "Deciding which cowpaths you want to pave.".

3) no matter what's written, it will be necessary to test to see if it matches implementations, which will have to be repeated anyway.

4) If you want an algorithm for taking a set of form entities and serializing them, you'll need to write it, because that isn't part of the definition of the data structure. We went through separating these back in the transition from RFC1867 ("File upload") in two, putting form processing in HTML and the actual definition of the data structure in RFC2388.

The algorithm for doing 'the reverse' probably needs to allow for compatibility with clients that implemented RFC2388, no matter what future restrictions you might want to impose. I"d think that doesn't belong in HTML, but I'm not sure server library implementors want or need pseudocode.