Re: multipart/form-data: Parsing PostStream

Giganews Newsgroups
Subject: Re: multipart/form-data: Parsing PostStream
Posted by:  Remy Lebeau \(Indy Team\) (re…@lebeausoftware.org)
Date: Tue, 16 Feb 2010

"Christian Kaufmann" <christian.kaufma…@gmx.net> wrote in message
news:thhin5l07lconc9bf4mb0ovgt9p5b68r…@4ax.com...

> 1) What is the save way to see the difference between the content of
> an edit control or a file upload?
> - Do I have to "know" it?
> - Can I rely on the field filename?

You need to support proper MIME parsing rules, per RFCs 2045-2049 and W3's
HTML 4+ specs. Each individual part in the stream reports its particular
data type in the 'Content-Type' header, as well as encoding information in
the 'Content-Disposition' and 'Content-Transfer-Encoding' headers.  You
cannot rely on filename alone, as text parts can have filenames, and binary
files are not required to have filenames.

> In my old code I checked for the Content-Type header.

You still need to do that.  Each part in the MIME stream has its own local
'Content-Type' header.

> Only file uploads had such a header.

When no 'Content-Type' header is present, you must use the default, which is
"text/plain; charset=us-ascii".

> But when I set the charset in an TIdHttp client, then also text fields get
> this header.

Setting a Charset at the TIdHTTP level assigns the charset to the top-level
'Content-Type: multipart/form-data' header for the entire request.  Do not
do that for 'multipart' submissions.  Use the CharSet for each MIME part
individually instead.  TIdMultipartFormDataStream allows for that.

> Content-Disposition: form-data; name="Data"
> Content-Type: text/plain; charset="UTF-8"
>
> From TIdHttp when using AddFormField

TIdMultipartFormData does not include an explicit charset attribute like
that unless you specify a Charset value for that text part.

--
Remy Lebeau (Indy Team)

Replies

None

In response to

multipart/form-data: Parsing PostStream posted by Christian Kaufmann on Mon, 15 Feb 2010