Re: Controlling Javascript from server side

Bart Van der Donck wrote:
Thomas 'PointedEars' Lahn wrote:
Bart Van der Donck wrote:
Thomas 'PointedEars' Lahn wrote:
The "Content-Type" header value of a HTTP message should always contain a
declaration of the encoding of the message body ("charset=...").
And in absence of which, the expected encoding is always ISO/IEC
8859-1, being the default HTTP charset ever since. It's not widely used
to set a character set here, unless, of course, you want something else
than ISO/IEC 8859-1.
That is specified so in HTTP/1.x.

Then it proves my argument Ita Scripta Est.

No, it does not, as the specification and the implementations differ here.

However, it is not implemented this way, as the HTML 4.01 Specification
points out: http://www.w3.org/TR/html401/charset.html#h-5.2.2

But it's not a bad habit nowadays to add it anyhow, especially in regard
to the growing Unicode support and further internationalization of the internet.
Declaring the character encoding was and still is a requirement for
interoperability.

http://www.w3.org/TR/html401/conform.html#h-4.3 clearly states that
charset is an *optional* parameter, how recommended it may be.

| The optional parameter "charset" refers to the character encoding used to
| represent the HTML document as a sequence of bytes. Legal values for this
| parameter are defined in the section on character encodings. Although this
| parameter is optional, we recommend that it always be present.

The reasoning for this recommendation is given in the section I have pointed
to. To ignore that recommendation is foolish, as we are talking about a Web
standard.

A javascript programme:
[ snip code ]
It is merely ECMAScript-3-conforming code, or such a script or program.
Then I suggest we rename this group to 'comp.lang.ECMAScript-3-
conforming-code'. [...]
I am not particularly inclined to support that.

Me neither. Come on. It was a joke.

You irony detector is borken.

While it is similar to the
correct name, ECMAScript implementations are *commonly* known as
"JavaScript". And it follows from Usenet practice that the name of a
newsgroup is not always the best or correct one; technical innovation
introduce new techniques that can be summarized under a common name because
of their similarities. Netscape JavaScript was the first implementation,
and the newsgroup has the greatest chance to be found under that name.

That does not mean it should not be pointed out to the people who actually
subscribe to this newsgroup that we are not dealing with one language named
JavaScript, but (at least) five different language implementations here.
The FAQ mentions it partly, and should emphasize it more.

The language is called javascript and browsers build their own
javascript engines. Many high-level languages work with different
compilers or may have environmental differences; but that doesn't mean
that the language isn't the same.

So you do *not* understand. There are not different "javascript engines",
there are different ECMAScript implementations. And that, again, is a
fundamental difference.

if (/\b(function|object)\b/i.test(typeof XMLHttpRequest)
&& _global.XMLHttpRequest)
Code for the lab.
No. Before you call something, you should be pretty sure that it can be
called; especially when you use it as a constructor for an object. It will
cause a runtime error and will make you look incompetent otherwise.

"if (window.XMLHttpRequest) { ..." is so widely used that I cannot
imagine this would ever be problematic. To be fair, I never saw
something else.

Assuming that there even is *window*.XMLHttpRequest is the first mistake.

Calling it without testing that it can be called is the next one.

Using it as a constructor without handling the case that this throws an
exception is the third one.

Early implementations of IXMLHTTPRequest in some environments (such as
Opera 8.0) provided the object, but did not provide it fully functional.
New implementations might also do that.

If your application is ever exposed to such an execution environment, it
will break; either silently in the background with nobody noticing it or
loud and clear as a nice big error message. Either way, the user will not
be able to interpret that in another way as "bad code".

Do I have to assume that you are going to blame the user for this?

var request = new ActiveXObject('MSXML2.XMLHTTP.3.0');
The inner working of MSXML is not accessible, so I follow the
guidelines recommended by Microsoft in their documentation. Seems a
reasonable approach to me.
"Microsoft.XMLHTTP" should suffice and select the most recent installed version.

Okay - it doesn't matter much, right ? I follow MSDN and say
'MSXML2.XMLHTTP.3.0',

Where the code will break because of the required COM/ActiveX object version
to be not installed, without the additional features of the newer version
being required here.

you say 'Microsoft.XMLHTTP'

I said that for a good reason.

and that will probably work too.

"Will probably work" is an expression of a Voodoo programmer. A reasonable
programmer would state "This code cannot possibly fail, because ...", and
rightly so.

request.open('GET', url, true);
'true' means that the request must be handled asynchronously. Makes
sense to me to set it here explicitly for code clarity that we want
async here and not sync (even when 'true' would be the default).
JFTR: `true' *is* the default.

I didn't say it wasn't. My argument was that the code becomes clearer
when 'true' is explicitly mentionned, as to indicate that the request
must be done asynchronously.

There is often an important gap in your arguments and this
demonstrates it clearly.

I seriously doubt that.

WHEN 'true' is the default,
AND people must *know* that 'true' is the default (which is far from
guaranteed),
AND it does not matter if it says 'true' or not,
THEN it is better to mention 'true' on that place.

It's not technical argument but an educational one, which certainly
stands on the same height.

You, the author of the code, now know that it is. Anyone interested in your
code will have to look up the meaning of the third argument anyway if they
are to understand what it does. I don't see the difference.

request.setRequestHeader('Content-Type', '');
That would make the HTTP request invalid,
No, the request will still be valid.
It will not.

Let's see. Can you name *one* browser or server where my request would
be invalid ? (thus, generating an error ?)

I am talking mostly servers, not user agents. However, you are trying to
shift the burden of proof; a common fallacy.

If you use a header like...
abc: 123
...it would still remain a valid request.
True, because of

,-<http://www.rfc-editor.org/rfc/rfc1945.txt>, 4.3
|
| Unrecognized header fields are treated as Entity-Header fields.

,-<http://www.rfc-editor.org/rfc/rfc1945.txt>, 7.1
|
| Entity-Header = Allow ; Section 10.1
| | Content-Encoding ; Section 10.3
| | Content-Length ; Section 10.4
| | Content-Type ; Section 10.5
| | Expires ; Section 10.7
| | Last-Modified ; Section 10.10
| | extension-header
|
| extension-header = HTTP-header

However:

| The extension-header mechanism allows additional Entity-Header fields
| to be defined without changing the protocol, but these fields cannot
| be assumed to be recognizable by the recipient. Unrecognized header
| fields should be ignored by the recipient and forwarded by proxies.

One should not disregard standards unless one has a very good reason
to do so. There is exactly *no* reason for such a thing here.

Indeed there is no reason, as it may create a wrong impression for the
reader of the code. You snipped my part where I said:

| You're correct that a false impression may be created here (as if
| the query string were offered as text/html or something, while it
| is always one ASCII percent-endoded string).

No, you are mixing up the cases here. With *any* non-standard header, you
are correct, and the above applies. However, with *your* _Content-Type_
header, the HTTP message clearly is invalid as the grammar of HTTP is not
followed.

if (request.responseText) {
That test would only handle the case (and improve efficiency a bit with the
code below) if the response body would be empty. It can be safely omitted.
I suppose it's quite possible that the body of the response would be
empty, like for instance a database that's not reachable.
However, an error status code is then indicated instead.

Not necessarily. A response might be perfectly desired and valid as
being empty.

You have been arguing that a database access error would be a valid reason
and now you are trying to wind out of that.

And what about feature testing ?
Not necessary here. When readyState == 4, responseText has to exist or the
implementation is FUBAR.

So you say that feature testing is necessary for:

document.getElementById('myField')

but obsolete for:

if (request.responseText) {

Very odd.

That is not odd at all. `document.getElementById()' is not backwards
compatible; `document' is. `request' is not backwards-compatible, and
neither is `request.responseText'; however, in contrast to document,
`request' is an implementation of a well-defined interface; it is
specified that request.responseText exists when readyState == 4.
BTW: The above would not qualify as a feature test anyway.

Of course the programmer must create an element with ID 'myField'. Of
course the programmer supposes that 'getElementById' is supported by
the client. Do you really believe that it's necessary to feature-test
on all these elementary things ? I don't.
I do. Because it always breaks with the client, not in the test cases.

So I suppose you advocate constructions like

if (window.alert) { window.alert('xx') }

That is *Miles* away from Praxis.

Fallacy #2: Drawing conclusions from supposed opinions.

If a `form' element would be written here that contained the `input'
element, the feature test for D::gEBI() above would be unnecessary.
Naturally, it's the intention that the original poster will not only
use <input>, but makes a total webpage with <form>, <html>, <body>
etc.
Should then not the most compatible solution be presented in the first place?

I presented basic code that demonstrated the working in a reasonable
way. Of course I should not have presented a "compatible solution" as
you seem to call it.

Yes, you should have, as that would have been presenting best common
practice, something of *real* value.

Look at the OP's reaction.

YMMD.

He quickly understands the code, what it does, how it works, what it
means and he has something workable in his hands.

He merely *thinks* he understands it because you did not explain the
pitfalls of your solution.

Math.random() gives me 15 to 18 digits after comma,
However, that is only the string representation of the IEEE-754 double;
the actual precision is much greater than that.

let's say 16 for easy calculation. A user would have 1 chance out of
10.000.000.000.000.000 that the next value is the same. With a 2
second refresh, the scope is 634.195.839 years. The difference is in
the head.
Different numeric values can have the same string representation, so the
chances are much greater than you think.

I was not talking about the values that are generated by
Math.random(), but about the sent URL's. These follow the
*representation* of the string and are not necessarily the
same as the result of the actual Math.random() call.

Which is the error in your reasoning.

"0.7546356374078109"

is the string representation of

0.7546356374078108665...
0.754635637407810867...
0.75463563740781087...
0.75463563740781088...
0.75463563740781089...
0.75463563740781090...
0.75463563740781091...
0.75463563740781092...
0.75463563740781093...
0.75463563740781094...
0.75463563740781095...
0.75463563740781096...
and
0.75463563740781097...

Of course I missed some, but that does not really matter.

BTW:
The precision of an IEEE-754 double-precision floating-point number is 64 bits.

But that does not really matter:

From the Law of Probability follows that any event E that can be the outcome
of a Random Experiment (i.e. P(E) > 0) may occur again the next time the
Random Experiment is performed, no matter how great the statistical
probability for for that event is. It is foolish to ignore that.

Statistically correct. I just wanted to demonstrate the rough scale.
The chance exists, but is negligible in practice here.

You are not only a fool who does not understand what he is doing, but also
an ignorant who ignores the correct explanation for his wrong-doing when he
is provided with it.


PointedEars
--
"Use any version of Microsoft Frontpage to create your site. (This won't
prevent people from viewing your source, but no one will want to steal it.)"
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
.

Relevant Pages

  • Re: Controlling Javascript from server side
    ... but five different language implementations here. ... 'true' means that the request must be handled asynchronously. ... There is exactly *no* reason for such a thing here. ... | percent-endoded string). ...
    (comp.lang.javascript)
  • Re: OT: sea level rise hmmmmm....
    ... what I do when there is a request I don't have time to ... publications, and with what I believe good reason, but right now I won't. ... of providing an informed digest. ... paper that later just _happens_ to have some policy impact doesn't ...
    (sci.electronics.design)
  • Re: [PHP] Looking for a reasonable explanation as to why $_REQUEST exists
    ... have a session variable they want to access and use $_REQUEST for it I ... I see no reason why people would not want to clearly ... superglobals before I really understood how important they were and ... So whether id comes from get or post doesn't matter ...
    (php.general)
  • Re: [PHP] Looking for a reasonable explanation as to why $_REQUEST exists
    ... have a session variable they want to access and use $_REQUEST for it I ... I see no reason why people would not want to clearly ... superglobals before I really understood how important they were and ... So whether id comes from get or post doesn't matter ...
    (php.general)
  • EAP Session
    ... in that the timeout is set to 1 second with no retries. ... EAP request/Identity has an ID set to 1 and every second another request is ... // which works around these misbehaving implementations. ... control over so changing the timeouts and retries is not an option. ...
    (microsoft.public.windowsce.platbuilder)