Re: Controlling Javascript from server side

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.

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.

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.

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.

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.

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', you say 'Microsoft.XMLHTTP' and that will
probably work too.

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.

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.

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 ?)

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

True, and that's exactly why it can be left empty in my code. No need
to write every <form> as <form enctype="application/x-www-form-
urlencoded"> neither.

You send a "Content-Type" header that has an empty value. That is
fundamentally different from sending no "Content-Type" header at all,
or sending it with the default value as specified in HTML 4.01.

Correct. It should not be specified.

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.

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.

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.

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. Look at the OP's reaction. He quickly understands
the code, what it does, how it works, what it means and he has
something workable in his hands.

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.

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.

--
Bart

.

Relevant Pages

  • Re: question on alternate function declaration syntax
    ... > think of a reason why it would cause problems (besides it being ... language grammars are written in a way that having no spaces between ... then the string to apply to the function. ... to "find" other than RootsOf. ...
    (comp.lang.java.programmer)
  • Re: Fix quilt merge error in acpi-cpufreq.c
    ... it is a pure cleanup. ... Language is not a "fit to one string" thing. ... YOU HAVE NEVER GIVEN A COHERENT REASON FOR FINDING IT USEFUL! ...
    (Linux-Kernel)
  • Re: (simple) question - function calls without ()
    ... reason for it. ... However setTimeout is being passed ... a string in this case and knows nothing about the ... not part of the actual language and so not in ECMAScript ...
    (comp.lang.javascript)
  • Re: Is C++ the "General Motors" of Programming Languages?
    ... On 22 Nov 2008 16:57:01 GMT, Bill Gunshannon wrote: ... I also see no reason why something like that needs to be a part of ... You can basicly define a string any way you want. ... I don't care if they come from the language, ...
    (comp.lang.misc)
  • Re: Operator overloading in C
    ... All development of C as an independent language has ... making any changes or improvements to the standard ... The lack of a counted string data structure, ... Pointers can't be used for arg1 or arg2. ...
    (comp.std.c)