By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,086 Members | 1,919 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,086 IT Pros & Developers. It's quick & easy.

does anyone declare a different data type on every input in a form?

P: n/a
I'm trying to read up on the rfc's that govern form inputs. Much of
what I'm reading is stuff I didn't know before and some of it is
alarming. This one left with me questions:

http://www.ietf.org/rfc/rfc1867.txt
Is this (below) addressed to me as a web designer, or is this
addressed to the makers of web browsers? Identifying the type of file
being uploaded seems way outside of my scope as a PHP coder. Am I
suppose to make clear the expected type of content when I design a
form? Off hand, I can only think of two things that every go into an
HTML form: strings and binary data. Should I actually label every
INPUT with the expected type (does anyone do this?), or can I assume
the makers of web browsers have already done that for me? My PHP form
code is fairly concise, so I could add in mime/text rather easily, but
is it necessary? Surely the browser knows that everything save binary
files is a string?

They wrote:

3.3 use of multipart/form-data

The definition of multipart/form-data is included in section 7. A
boundary is selected that does not occur in any of the data. (This
selection is sometimes done probabilisticly.) Each field of the form
is sent, in the order in which it occurs in the form, as a part of
the multipart stream. Each part identifies the INPUT name within
the
original HTML form. Each part should be labelled with an appropriate
content-type if the media type is known (e.g., inferred from the
file
extension or operating system typing information) or as
application/octet-stream.
They give the example below. Am I right to say that I don't need to
think about any of this, that the web browser does all this
automatically? The browser figures out that file2.gif is a gif image
that needs to be sent with a the header Content-type: image/gif, yes?

If the user also indicated an image file "file2.gif" for the answer
to 'What files are you sending?', the client might client might
send
back the following data:

Content-type: multipart/form-data, boundary=AaB03x

--AaB03x
content-disposition: form-data; name="field1"

Joe Blow
--AaB03x
content-disposition: form-data; name="pics"
Content-type: multipart/mixed, boundary=BbC04y

--BbC04y
Content-disposition: attachment; filename="file1.txt"
Content-Type: text/plain

... contents of file1.txt ...
--BbC04y
Content-disposition: attachment; filename="file2.gif"
Content-type: image/gif
Content-Transfer-Encoding: binary

...contents of file2.gif...
--BbC04y--
--AaB03x--

Also, can anyone help me understand this? If I wanted to send multiple
files as part of a form input, how would I use the multipart/mixed
header, or the "content-transfer-encoding" header? Can anyone point me
to an example, so I might have a better chance of understanding this?

http://www.ietf.org/rfc/rfc2388.txt
As with all multipart MIME types, each part has an optional
"Content-Type", which defaults to text/plain. If the contents of a
file are returned via filling out a form, then the file input is
identified as the appropriate media type, if known, or
"application/octet-stream". If multiple files are to be returned
as
the result of a single form entry, they should be represented as a
"multipart/mixed" part embedded within the "multipart/form-data".

Each part may be encoded and the "content-transfer-encoding" header
supplied if the value of that part does not conform to the default
encoding.
Jul 17 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a
lawrence wrote:

[ ... ]
http://www.ietf.org/rfc/rfc1867.txt

Is this (below) addressed to me as a web designer, or is this
addressed to the makers of web browsers?


Section 3.3 outlines the browser's job when using
multipart/form-data, so it's largely irrelevant to web
designers. It might be useful to understand the goings-on
though.

I can't recommend anything other than the two RFCs you
mentioned (nos. 1867 and 2388) and chapter 17 of the HTML
spec. It's all there.

[ ... ]

Have a good Sunday! if there's anything left.

--
Jock
Jul 17 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.