469,926 Members | 1,533 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,926 developers. It's quick & easy.

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

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:

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
original HTML form. Each part should be labelled with an appropriate
content-type if the media type is known (e.g., inferred from the
extension or operating system typing information) or as
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
back the following data:

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

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

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

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

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

...contents of file2.gif...

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?

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
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
Jul 17 '05 #1
1 2762
lawrence wrote:

[ ... ]

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

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.

Jul 17 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

10 posts views Thread by Gregory A Greenman | last post: by
4 posts views Thread by Brian Glen Palicia | last post: by
15 posts views Thread by greenflame | last post: by
52 posts views Thread by Julie | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.