By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,387 Members | 1,729 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,387 IT Pros & Developers. It's quick & easy.

xmlttp not sending all encodeURIComponent data

P: n/a
Greetings,

I'm trying to send data to my server using xmlhttp POST. The data being
sent is actually an HTML page that is built with javascript in the
browser. The HTML code contains a small javascript function in the
<HEAD> section. I applied encodeURIComponent to the data prior to
sending it but anything between the <script> </script> tags does not
get sent. The tramsmitted data is cought by a Perl script on the
server, it handles the input as normal FORM data and writes the html
data sent to a file (with the javascript function missing). Maybe I
need to do something different related to encoding the chars for an
HTML comment (?)

Snippit of the HTML data I'm trying to send -

<HTML><HEAD><TITLE>/TITLE>
<script>
<!--
function popLink(popurl){
var options = "";
var width="500";
var height="500";
blah
}
//-->
</script>
</HEAD><BODY BGCOLOR=WHITE>

The entire HTML gets sent with everything between <script> and
</script> missing.

Any assistance/pointers are most appreciated.
Thanks !!
Steve

Here's the POST that's being issued -

xmlhttp.open("POST", 'http://myserver.com/cgi-bin/xmlStoreFile.pl',
true);
xmlhttp.onreadystatechange=function() {
if (xmlhttp.readyState==4) {
store_server_reply = xmlhttp.responseText;
}
else{
store_server_reply = 'ERROR';
}
}
xmlhttp.setRequestHeader('Content-Type',
'application/x-www-form-urlencoded; charset=UTF-8');
xmlhttp.send('file='+encodeURIComponent(fn)+'&type ='+encodeURIComponent(ext)+'&data='+encodeURICompo nent(data)+'&option='+encodeURIComponent(opt)+'&st ripuserid='+encodeURIComponent(id));

Jul 23 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
VK
I guess in this particular case you will have much more cross-browser
compatibility by using the status "204 No Content". XMLHTTP here is
like hammering the nails with microscope :-)

Gust have a regular form and submit it in the regular way via
mForm.submit().

Your Perl script should process data and respond by
print "Status: 204 No content\n";
print "Cookie: status=".$status."\n";
print "\n";

where $status can be checked on client-side before the next submission.
There is a small bug in IE 5.5 and IE 5.5 SP1 (not before and not
after). It causes the browser to stay in "waiting data" mode until the
system timeout. So the cursor will "hourglassing" for 5-15 sec after
each submission. But I guess it's nothing in comparison of
XMLHttpRequest POST issues across current browsers.

Also make sure that your "<script>" and "</script>" never ever incur in
full form. For autogenerated scripts always use something like:
str+= "<scr" + "ipt>" + code + "</scr" + "ipt>";

Jul 23 '05 #2

P: n/a
VK
> Not sure how I can check for a server response if I submit the request using a regular form

"204 No Content" header forces the browser to stay on the same page (as
like you did not submit it). At the same time it will update metadata
(including session cookie) sent from the server. That was the trick
used before XMLHTTPRequest. I mean you submit the form, server sends
print "Status: 204 No content\n";
print "Cookie: status=".$status."\n";
print "\n";

so later you can check the situation by reading (via JavaScript)
"status" cookie. But maybe now (I mean everything after 5th versions of
everything) they broke it or lock it.

Concerning <script> tag: it's a mistery for myself.

document.write("<script>");
or
document.write("<scr"+"ipt>");
or
document.write("<scr");
document.write("ipt>");

are programically equal. But often it does make some big misterious
difference for some misterious security check.

Jul 23 '05 #3

P: n/a
VK wrote:
I guess in this particular case you will have much more cross-browser
compatibility by using the status "204 No Content". XMLHTTP here is
like hammering the nails with microscope :-)

Gust have a regular form and submit it in the regular way via
mForm.submit().

Your Perl script should process data and respond by
print "Status: 204 No content\n";
There is no such thing as a `Status' response header in HTTP/1.0
or HTTP/1.1. The response should instead start with

HTTP/1.x<SP>204<SP>No content<CRLF>

(where x=0 or x=1) and the Perl script that generated it should
read at least

print "HTTP/1.0 204 No content\r\n";

See <http://en.wikipedia.org/wiki/HTTP#Sample>, and RFC 1945 and
RFC 2616, both section 6, for details.
print "Cookie: status=".$status."\n";
There is no such thing as a `Cookie' header in an HTTP *response*. `Cookie'
is a header reserved for HTTP *requests* to send all site-relevant cookies
from the client to the server. The name of the HTTP response header to set
cookies server-side (i.e. have the server "ask" the client whether to set a
cookie or not, as opposed to a client-side application "asking" the user
agent) is quite obvious: `Set-Cookie'.

See e.g. <http://en.wikipedia.org/wiki/HTTP-Cookie>
print "\n";
And all request and response lines except the last one are to be delimited
with CRLF, i.e. "\r\n" in Perl.
Also make sure that your "<script>" and "</script>" never ever incur in
full form.
This applies for CDATA within HTML `script' elements only.
For autogenerated scripts always use something like:
str+= "<scr" + "ipt>" + code + "</scr" + "ipt>";


(Again) absolutely no(t), because that does not work around the ETAGO (End
Tag Open) delimiter issue: Whenever script CDATA content is included in a
document of an *SGML based markup language* (like HTML) and includes string
literals containing end tags, the ETAGO delimiter (`</') should be escaped
as it otherwise indicates the end of CDATA content and thus the end of the
script element. In JS/ECMAScript this can be done in the simplest way
using

<\/

as `\' is the escape character in string literals, `\/' is not recognized
as a known escape sequence and thus expanded to `/' only.

Bottom line:

You appear to not have read anything (specs, previous discussions) before
you post and "recommend" (falsely) or even tested once properly what you
recommend. When is that going to change? There is nothing wrong with
being wrong (this is where knowledge comes from), but you are currently
distributing, repeatedly and deliberately, only half-knowledge (if that)
which you are trying to mislabel as expert knowledge; clearly a Bad Thing.
PointedEars
--
But he had not that supreme gift of the
artist, the knowledge of when to stop.
-- Sherlock Holmes
Jul 23 '05 #4

P: n/a
Thomas 'PointedEars' Lahn wrote:
VK wrote:
Also make sure that your "<script>" and "</script>" never ever incur in
full form.


This applies for CDATA within HTML `script' elements only.


And for close tags only, of course, so ...
For autogenerated scripts always use something like:
str+= "<scr" + "ipt>" [...]


.... this could not be more wrong, taking into account that
the required `type' attribute is also missing.
PointedEars
Jul 23 '05 #5

P: n/a
VK wrote:
Not sure how I can check for a server response if I submit the request
using a regular form
"204 No Content" header forces the browser to stay on the same page (as

^^^^^^ like you did not submit it). At the same time it will update metadata
(including session cookie) sent from the server. That was the trick
used before XMLHTTPRequest. I mean you submit the form, server send ^^^^^^^^^^^ print "Status: 204 No content\n"; ^^^^^^^ ^^ print "Cookie: status=".$status."\n"; ^^^^^^^ ^^ print "\n"; ^^ so later you can check the situation by reading (via JavaScript) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ "status" cookie. But maybe now (I mean everything after 5th versions of ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^ everything) they broke it or lock it. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Concerning <script> tag: it's a mistery for myself.

document.write("<script>");
or
document.write("<scr"+"ipt>");
or
document.write("<scr");
document.write("ipt>");

are programically equal. But often it does make some big misterious ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^ difference for some misterious security check.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
That is complete, absolute, utter nonsense. Even more, it is FUD garbage.
Please stop posting in technical newsgroups like this until you have gained
a minimum clue. Thanks in advance.
PointedEars, Score adjusted
--
But he had not that supreme gift of the
artist, the knowledge of when to stop.
-- Sherlock Holmes
Jul 23 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.