Thanks to George C. Hawkins for clearing up the
specification and to Pier Fumagalli for correcting the
spelling of my last name.
It is now clear that interpreting b="" as I suggested
earlier would be wrong. But interpreting b=null might
not be. Section 8.2.1 of RFC 1866, describing the
form-urlencoded Media Type, says that "The fields are
listed in the order they appear in the document with
the name separated from the value by '=' and the pairs
separated from each other by '&'. Fields with null
values *may* be ommitted". (Emphasis mine)
This seems to suggest that a null value may be sent,
and the only way to differentiate a null value from an
empty string would be to omit the '=' sign -- if there
is no value, then adding separating the name from
value with an equal sign makes no sense.
Under this interpretation, the contents of the
hashtable would not change, and no developer's
previous assumption need change. Further, it would
allow for a seemingly valid interpretation of the spec
for the application/x-www-form-urlencoded mime type.
Regards,
Rob
--- "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
> On Mon, 3 Sep 2001, George C. Hawkins wrote:
>
> > Date: Mon, 3 Sep 2001 16:52:32 +0100
> > From: George C. Hawkins <[EMAIL PROTECTED]>
> > Reply-To: [EMAIL PROTECTED],
> > George C. Hawkins <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]
> > Subject: RE: Bug/Fix for
> HttpUtils.parseQueryString - IMPORTANT!
> >
> > I do not believe Mr. Lucifer's "patch" should be
> applied. As has been
> > pointed out a number of times Tomcat is the
> reference implementation for
> > the JSP and servlet JCRs.
> >
> > In the Servlet 2.3 PFD2 specification you find the
> following in the
> > definition of parseQueryString():
> >
> > "The query string should be in the form of a
> string packaged by the
> > GET or POST method, that is, it should have
> key-value pairs in the
> > form key=value, with each pair separated from
> the next by a &
> > character."
> >
> > People regularly ask for "features" that run
> contrary to the
> > specification (e.g. a common request/confusion is
> that parsePostData()
> > should handle the "multipart/form-data" encoding)
> - these requests are
> > turned down. If you want to change/query the
> specification talk to the
> > JCR people not to the Tomcat implementers!
> >
>
> As a practical matter, the suggested change would
> indeed violate the spec,
> and therefore should not be applied unless the spec
> were to be changed.
>
> In addition, it should be noted that the entire
> HttpUtils class has been
> deprecated in Servlet 2.3, because its methods are
> hopelessly inadqueate
> for dealing with requests that are not in the
> server's default character
> encoding. Therefore, it is pretty unlikely that
> suggested changes to this
> class will be incorporated into future versions of
> the spec.
>
> Once you migrate to a 2.3-based container, you can
> call
> ServletRequest.getParameterMap() to get a
> (read-only) Map of all the
> request parameters for this request (from both the
> query string and the
> body of POST requests), suitably converted into
> Unicode for you. If you
> want to process the query string in some different
> fashion, you can call
> HttpServletRequest.getQueryString() and parse it
> yourself.
>
> Craig McClanahan
>
__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com
