Re: what should the charset be in the response to the server

I said:


>
>  "Jungshik Shin" replied at: Saturday, July 26, 2003 11:31 AM
>
>
> >
> > On Sat, 26 Jul 2003, Chris Haynes wrote:

<snip>

> >
> > > The only other reliable transfer mechanism available would
appear
> to
> > > be  the ENCTYPE="multipart/form-data" method being discussed in
> this
> > > same thread, but this format is not decoded by standard Servlet
> > > containers, so the convenient HttpRequest.getParameter() Servlet
> API
> > > could not be used with this mechanism.
> >
> >    Can this API be updated to decipher charset parameter present
in
> > C-T header fields of subparts of multipart/form-data? HTML 4.x was
> > released in 1999(?) and .....
> >
>
> I don't see why not. It would seem to be architecturally possible.
>
> Sun's Servlet spec. 2.3 (and final draft 3 of  version 2.4) say that
> only application/x-www-form-urlencoded is to be used as a source of
> parameters when POST is used (sect 4.1.1).
>
> It seems to be illogical that, from a page designer's  point of
view,
> there are three different ways of returning the same data, yet
Servlet
> containers only support the two which use query-string encoding -
and
> the one they don't support is the only one that carries with it an
> unambiguouis indication of the character encoding used!.
>
> It's probably too late in the 2.4 cycle to propose this change.
Maybe
> someone should do so for 2.5.
>
> >
> >    Jungshik
> >
> >
> >
>
> Chris


On further reflection, I think there _is_ an architectural reason why
Sun could not include  multipart/form-data as a source of Servlet
parameters. Parameters are delivered as Java Strings, and
multipart/form-data can contain non-textual parts, such as uploaded
binary files.

A Servlet / application developer would have to supply her own MIME
and character decoding to use multipart/form-data .

Chris

Received on Saturday, 26 July 2003 08:22:16 UTC