xmlttp not sending all encodeURIComponent data

F

fochie

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='+encodeURIComponent(data)+'&option='+encodeURIComponent(opt)+'&stripuserid='+encodeURIComponent(id));
 
V

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>";
 
F

fochie

Thanks for the reply.

I put an alert in just prior to issuing the xmlhttp POST to test that
all data was there prior to issuing the POST (also though prior to the
data being subjected to encodeURIComponent) and the full
respresentation of the HTML that I built is displayed). I've been
testing strictly with FireFox lately.

I was using this approach since I also need information back from the
server, after the HTML is stored, and wanted to use the seemless
interface that xmlhttp supplies. I'm confused on your suggestion. Not
sure how I
can check for a server response if I submit the request using a regular
form ...or is there a way to to use both an xmlhttp POST and regular
form data submission processing ? I guess I could also implement the
cludge of changing the <script> <!-- and --></script> tags
temporarily to something my Perl CGI will recognize and change back
once received. Just wasn't sure why these particular tags were causing
the data within them to not be either translated or transmitted.
 
V

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.
 
T

Thomas 'PointedEars' Lahn

VK said:
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";

and RFC 1945 and said:
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. said:
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
 
T

Thomas 'PointedEars' Lahn

VK said:
"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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top