xmlttp not sending all encodeURIComponent data

VK · Jul 23 '05, 08:34 PM

Re: xmlttp not sending all encodeURICompon ent data

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=".$statu s."\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 "hourglassi ng" 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>";

VK · Jul 23 '05, 08:35 PM

Re: xmlttp not sending all encodeURICompon ent data

> 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=".$statu s."\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.

**Thomas 'PointedEars' Lahn** · Jul 23 '05, 08:55 PM

Re: xmlttp not sending all encodeURICompon ent data

VK wrote:
[color=blue]
> 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";[/color]

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>N o 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.or g/wiki/HTTP#Sample>, and RFC 1945 and
RFC 2616, both section 6, for details.
[color=blue]
> print "Cookie: status=".$statu s."\n";[/color]

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.or g/wiki/HTTP-Cookie>
[color=blue]
> print "\n";[/color]

And all request and response lines except the last one are to be delimited
with CRLF, i.e. "\r\n" in Perl.
[color=blue]
> Also make sure that your "<script>" and "</script>" never ever incur in
> full form.[/color]

This applies for CDATA within HTML `script' elements only.
[color=blue]
> For autogenerated scripts always use something like:
> str+= "<scr" + "ipt>" + code + "</scr" + "ipt>";[/color]

(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

**Thomas 'PointedEars' Lahn** · Jul 23 '05, 08:55 PM

Re: xmlttp not sending all encodeURICompon ent data

Thomas 'PointedEars' Lahn wrote:
[color=blue]
> VK wrote:[color=green]
>> Also make sure that your "<script>" and "</script>" never ever incur in
>> full form.[/color]
>
> This applies for CDATA within HTML `script' elements only.[/color]

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

.... this could not be more wrong, taking into account that
the required `type' attribute is also missing.

PointedEars

**Thomas 'PointedEars' Lahn** · Jul 23 '05, 08:55 PM

Re: xmlttp not sending all encodeURICompon ent data

VK wrote:
[color=blue][color=green]
>> Not sure how I can check for a server response if I submit the request
>> using a regular form[/color]
>
> "204 No Content" header forces the browser to stay on the same page (as[/color]
^^^^^^[color=blue]
> 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[/color]
^^^^^^^^^^^[color=blue]
> print "Status: 204 No content\n";[/color]
^^^^^^^ ^^[color=blue]
> print "Cookie: status=".$statu s."\n";[/color]
^^^^^^^ ^^[color=blue]
> print "\n";[/color]
^^[color=blue]
> so later you can check the situation by reading (via JavaScript)[/color]
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^[color=blue]
> "status" cookie. But maybe now (I mean everything after 5th versions of[/color]
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^[color=blue]
> everything) they broke it or lock it.[/color]
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^[color=blue]
> 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[/color]
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^[color=blue]
> difference for some misterious security check.[/color]
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^
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

xmlttp not sending all encodeURIComponent data

xmlttp not sending all encodeURIComponent data

Comment

Comment

Comment

Comment

Comment