in RFC 2388: Returning Values from Forms: multipart/form-data (http://www.ietf.org/rfc/rfc2388.txt)
in paragraph 4.1 "Boundary" it says: "As with other multipart types, a boundary is selected that does not occur in any of the data." later on it says: ..."For example"... "--AaB03x" Now when I tested my code, that grabs data sent from a multipart/form-data encoded form, I saw that Lynx (versions 8.2.3 and 8.2.4 which I used) always returned: xnyLAaB03X as a boundary. In this boundary "xnyL" is the mirrored equivalent of "Lynx" and "AaB03x" is being taken literally from the author's example, but now with capital X at the end... Other browsers use a "unique key" in their boundary like: ---------------------------7d217b185909c4 with the extra "--" at the start it would make: -----------------------------7d217b185909c4 that changes with every post of the form: -----------------------------7d2104253a090c in Internet Explorer, or: -----------------------------41184676334 in Mozilla 1.0 To replicate the error that I came about do the following: - Use a Lynx browser. - Fill out a form with enctype="multipart/form-data" - put "--xnyLAaB03X" in an input text field or textarea. This will rise an error in the server code that has to interpret the data. To give an example: it wouldn't be possible to post this very text in a multi-part/formdata encoded form using Lynx! I would propose using an equivalent approach (a unique key) as used in other browsers and as: RFC 1867 : Form-based File Upload in HTML (http://www.ietf.org/rfc/rfc1867.txt) already proposed: "A boundary is selected that does not occur in any of the data. (This selection is sometimes done probabilisticly.)" Allan ===== __________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ ; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to [EMAIL PROTECTED]
