XMLHttpRequest and <input type="textbox"> value escaping

[msoliver]

I've run into a rather simple bug with the XMLHttpRequest object that
is exposed in FF, Chrome, and IE for AJAX calls. If I have the
following on a web page (anywhere):

<input type="text" value="&lt;Test"/>

then the XMLHttpRequest send will not work. The server never sees the
request. I've also tried Unicode-based encoding, <. If instead,
the tag is this:

<input type="text" value="&lt; Test"/>

All is well. Putting the space between the entity and a following
character makes the difference. The server callback works.

So, my question is: what's the workaround for this? How do I put the
"<" character as part of the value attribute of a <input> control?
Putting a space between the escaped < and other characters seems like
a huge hack.

I've verified that this is a bug with IE as well as Firefox and Chrome
- also verfied that this is unrelated to the AJAX implementation since
I tried it on a variety of different server-side environments. This
appears to be a client-side browser error.

Seems like a fundamental syntactical error here that is messing up
XMLHttpRequest. Any insight would be appreciated.

Thanks,

Mike Oliver

 

[JR]

Hi Mike,
Have you tried using Javascript's escape() (in post mode) or
encodeURIComponent() (in get mode) to pass the input value to your
Ajax function?

Cheers,
Joao Rodrigues

 

[David Mark]

Hi Mike,
Have you tried using Javascript's escape() (in post mode) or
encodeURIComponent() (in get mode) to pass the input value to your
Ajax function?

Very odd advice, indeed. There's no correlation between escape and
post or encodeURIComponent and get. You use encodeURIComponent when
possible and fall back to escape (for either submission method.)

 

[JR]

Dear David,
I was mistaken while looking at some old code lines I wrote a few
months ago, using escape (just one variable and post method) and
encodeURIComponent (url containing two variables and get method) just
for testing purpose. Then these two functions fell through the
cracks...

Thanks.

Joao Rodrigues

 

[JR]

Hi David,
Now I remember why I tested escape() and encodeURIComponent() in my
Ajax function: I was sending a select tag value containing accented
character, e.g. México (in Portuguese, Mexico is written with é, as
América). So I used:

escape('México') -> returned "M%E9xico"

and

encodeURIComponent('México') -> returned "M%C3%A9xico"

You see, there's a difference between these two functions when it
comes to accented chars. Depending on the charset (UTF-8 or
iso-8859-1) defined in my ASP page called by XMLHttpRequest object
(Ajax), there can be disparate results. That's why I may need escape()
instead of encodeURIComponent().

Cheers,
Joao Rodrigues

 

[Thomas 'PointedEars' Lahn]

I've run into a rather simple bug with the XMLHttpRequest object that
is exposed in FF, Chrome, and IE for AJAX calls. If I have the
following on a web page (anywhere):

<input type="text" value="&lt;Test"/>

then the XMLHttpRequest send will not work.

<http://www.jibbering.com/faq/faq_notes/clj_posts.html#ps1DontWork>

(JFTR: The FAQ is back on line.)

The server never sees the request.

Maybe because none is made in the first place?

I've also tried Unicode-based encoding, <. If instead,
the tag is this:

<input type="text" value="&lt; Test"/>

All is well. Putting the space between the entity and a following
character makes the difference. The server callback works.

Since the markup as-is is not supposed to make a difference, it could be
that there is a client-side ("unobtrusive") script that modifies the
behavior of the form if it sees the correct `value' attribute value (`value'
property). However, that would be quite an odd implementation.

So, my question is: what's the workaround for this?

Understanding what you are doing.

How do I put the "<" character as part of the value attribute of a
<input> control?

As you did. Your problem probably lies elsewhere.

Putting a space between the escaped < and other characters seems like
a huge hack.

It is nonsense, caused by your not understanding what you are doing.
It starts with your using XHTML syntax and maybe XHTML instead of HTML -- why?

I've verified that this is a bug with IE as well as Firefox and Chrome
- also verfied that this is unrelated to the AJAX implementation since
I tried it on a variety of different server-side environments. This
appears to be a client-side browser error.

Since you have not explained the whole context, so far it appears to be
unexpected but not necessarily erroneous behavior of the UA, caused by
invalid markup and/or error correction employed when serving XHTML as text/html.

Suffice it to say that I have never encountered this problem in the named
browsers with a variety of XHR-enabled and other forms even though the
application server that we are using, Zope, forces us to serve XHTML as
text/html for documents that are dynamically generated server-side.

Seems like a fundamental syntactical error here that is messing up
XMLHttpRequest. Any insight would be appreciated.

<http://validator.w3.org/>


PointedEars

 

[Bart Van der Donck]

Very odd advice, indeed.  There's no correlation between escape and
post or encodeURIComponent and get.  You use encodeURIComponent when
possible and fall back to escape (for either submission method.)

IMHO it might be perfectly desirable to use ISO-8859-1 as a well-
thought choice, and consequently use that character set in all aspects
of the application. When working with Western data, this is mostly my
preferred encoding; certainly not a fallback. I have found that
especially for middleware applications Unicode can be a real pain.
"Think globally, act locally" would be my advice in this matter.

 

[David Mark]

IMHO it might be perfectly desirable to use ISO-8859-1 as a well-
thought choice, and consequently use that character set in all aspects
of the application. When working with Western data, this is mostly my
preferred encoding; certainly not a fallback. I have found that
especially for middleware applications Unicode can be a real pain.
"Think globally, act locally" would be my advice in this matter.

My point is that you do the same thing, regardless of the submission
method. Best practice is to detect encodeURIComponent first as escape
is limited.

 

[msoliver]

<http://www.jibbering.com/faq/faq_notes/clj_posts.html#ps1DontWork>

(JFTR: The FAQ is back on line.)


Maybe because none is made in the first place?




Since the markup as-is is not supposed to make a difference, it could be
that there is a client-side ("unobtrusive") script that modifies the
behavior of the form if it sees the correct `value' attribute value (`value'
property).  However, that would be quite an odd implementation.


Understanding what you are doing.


As you did.  Your problem probably lies elsewhere.


It is nonsense, caused by your not understanding what you are doing.
It starts with your using XHTML syntax and maybe XHTML instead of HTML --why?


Since you have not explained the whole context, so far it appears to be
unexpected but not necessarily erroneous behavior of the UA, caused by
invalid markup and/or error correction employed when serving XHTML as text/html.

Suffice it to say that I have never encountered this problem in the named
browsers with a variety of XHR-enabled and other forms even though the
application server that we are using, Zope, forces us to serve XHTML as
text/html for documents that are dynamically generated server-side.


<http://validator.w3.org/>

PointedEars

Troll

 

[msoliver]

Very odd advice, indeed.  There's no correlation between escape and
post or encodeURIComponent and get.  You use encodeURIComponent when
possible and fall back to escape (for either submission method.)

Thanks for all your responses - A clarification. The <input> tag is
unrelated to the XMLHttpRequest. THe HTML element just happens to be
on the page. The paramaters sent via the request are just test
strings, no encoding. The issue seems to be that the <input> tag with
the value attribute encoding seems to put the XMLHttpRequest DOM
object in a bad state since as soon as it is used, it fails. Here is
an example page that hopefully shows in more detail what I'm talking
about. The CallServer method is what does the request. Again, if I put
a space between &lt; and "test" in the value attribute below, I get
back a server response, if I don't, the server never gets the request.
And, preemptively, if somehow after all of this exposition, a reader
might not thing I have a grasp of the technologies or don't understand
encoding techniques, AJAX, etc. - please just keep your comments to
yourself:

<%@ Page Language="C#" AutoEventWireup="true"
CodeFile="Default.aspx.cs" Inherits="_Default" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://
www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
<title>Untitled Page</title>
</head>
<body>
<form id="form1" runat="server">
<input type="text" value="&lt;test" />
</div>
</form>

<script type="text/javascript">

function docall()
{
var oReq = new AjaxRequest("Test", "Param1", "Val1");
oReq.send();
}

function callback(sData, sContext)
{
alert(sData);
}

var g_sLevel1Sep = "\x01";

AjaxRequest = function(sReqName, sName1, sVal1, sName2, sVal2,
sName3, sVal3)
{
this.addParam = function(sName, sValue)
{
sReqString += (sName + "=" + sValue + g_sLevel1Sep);
}

this.send = function()
{
if (typeof(CallServer) == "undefined")
alert("ERROR; Ajax not enabled for this page.");
else
CallServer(sReqString);
}

this.sendasync = function()
{
setTimeout(this.send, 100);
}

var sReqString = "op=" + sReqName + g_sLevel1Sep;
if (sName1 && typeof(sVal1 != "undefined"))
this.addParam(sName1, sVal1);
if (sName2 && typeof(sVal2 != "undefined"))
this.addParam(sName2, sVal2);
if (sName3 && typeof(sVal3 != "undefined"))
this.addParam(sName3, sVal3);
}

</script>
</body>
</html>

 

[Thomas 'PointedEars' Lahn]

[Full quote of possible explanations snipped]

Troll

*PLONK*