[Bug 6742] pre-encoded form values should be restorable as submitted

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6742





--- Comment #4 from Nick Levinson <Nick_Levinson@yahoo.com>  2009-03-29 05:22:42 ---
No, I was referring to <http://www.w3.org/TR/html5/> (presumably
http://www.w3.org/TR/2009/WD-html5-20090212/). I didn't even know about the two
you cited; I've now gone through them in some detail. (Accesses were Mar.
27-28, 2009.) The corresponding provisions in the documents you cited is in
sections 4.10.15.4 through -.6 of the WHAT WG document
(http://www.whatwg.org/specs/web-apps/current-work/>, Draft Recommendation, 28
March 2009 (the same date appeared when accessed on the 27th)). The other doc
(Editor's Draft (24 March 2009), accessed 27th) doesn't cover it.

For example, WHAT WG's section 4.10.15.4, step 6, substep 1, requires replacing
a section symbol with &167; and substep 2 requires replacing an ampersand with
%26, yielding %26167;. This will be reversed later, presumably first to recover
an ampersand and then for a section symbol. But if the submitter originally
entered literally &167; into the field that is now being encoded, then
restoration will still result in a section symbol even though the submitter
never typed one. The result will thus differ from what was submitted.

But it's not a good idea to turn encoding off or make it optional, because
unencoded data streams present security risks. Instead, what's needed is a
method for knowing that certain strings should not be reversed because they
only look reversible but actually were not due to encoding by a user agent.
Given such a method, encoding can still be completed within the UA, ensuring
safety.

Two methods are available: listing and flagging strings not to be reversed.

A flag cannot be universal, as it, too, then becomes susceptible to the same
problem described above. But a flag can be nonappearing in one string (such as
a URL's query string) in which it will be used. For example, if pkXwq doesn't
appear, then pkXwq can become that flag, placed both before and after the
string that is not to be reversible and in a separate user-noneditable field
that declares what specific string is the flag. For the next submission, jjt
might be the flag.

The other method, listing, would construct a separate list of strings not to be
reversed. If a string is reversible if it's in one location but not if it's in
another, the location of the string not to be reversed would be in the list. If
a string is reversible if it's in many locations but not if it's in one or a
few particular locations, the locations of the many strings to be reversed
would be given instead of the location/s of the string not to be reversed, the
latter option intended to shorten the transmission length but requiring a T/F
value to indicate that the list is of what to reverse rather than of what not
to reverse.

Flagging is likely more efficient. Both require programming in an
implementation but flagging probably makes a shorter URL than would listing.

On the other hand, is it possible that reversal is already selective and I just
haven't seen a mechanism or specification for it? A database management system
could handle it but would have to know when, and for that the sender's UA would
have to be the informant. Have I missed something?

Thanks.

-- 
Nick


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Sunday, 29 March 2009 05:22:54 UTC