Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: tomcat-dev@jakarta.apache.org
Message-ID: <006e01c134de$90111ff0$1100a8c0@petya>
Reply-To: "George C. Hawkins" <george.hawkins@pobox.com>
From: "George C. Hawkins" <george.hawkins@pobox.com>
To: <tomcat-dev@jakarta.apache.org>
References: <20010903112311.J81157-100000@localhost>
Subject: Re: Bug/Fix for HttpUtils.parseQueryString - IMPORTANT!
Date: Tue, 4 Sep 2001 02:11:07 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

> Thanks to George C. Hawkins for clearing up the
> specification and to Pier Fumagalli for correcting the
> spelling of my last name.

Oops sorry about the misspelling - it genuinely wasn't intentional - Freudian
slip maybe :-) Sorry if my first e-mail was a bit dogmatic.

> 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)

I don't think there's a real concept of null in HTML forms as there is in
languages with references and/or pointers. In a HTML form there's no way to
enter a null value.

To me a so called null value is equivalent to the empty string in the context of
HTML form elements, and such null values if represented in a query string would
be encoded as "bar=" and methods such as parseQueryString() will treat such
elements as if they really had been omitted from the query string, i.e. ignore
them.

It's always been an irritation to me that when updating a bean using:

  <jsp:setProperty name="foo" property=="*" />

that properties that have a text value (or a value that can be mapped to and
from a string) are not updated to have the value empty string if the user
entered no text into the corresponding HTML form element (or deleted the text in
the form element if it'd been set to the previous value of the property). But
hey that's life :-)

[ Is there now a standard function or de-facto accepted piece of boiler plate
for this situation (for beans where either all properties correspond to HTML
form elements or you somehow mark the ones that are)? ]

Anyway that's my take - I haven't been keeping up with things since 2.2 - Craig
points out there are cool new methods in 2.3. Just took a look at the changes
section in the Servlet 2.3 PFD2 spec and I'd have to say the corresponding
section in the JSP 1.2 PFD2 spec is much more developer friendly.

Yours,


George.