setTimeout not executing form submit

M

Mic

Goal: delay execution of form submit

Code (Javascript + JScript ASP):

<%
Response.Write("<OBJECT ID='IntraLaunch' STYLE='display : none'
WIDTH=0 HEIGHT=0 CLASSID='CLSID:0AE533FE-B805-4FD6-8AE1-A619FBEE7A23'
CODEBASE='IntraLaunch.CAB#version=5,0,0,3'>")
Response.Write("<PARAM NAME='ImageLoc' VALUE='Null'>")
Response.Write("<PARAM NAME='ImageSrc' VALUE='Null'>")
Response.Write("<PARAM NAME='Run'
VALUE='F:\\Axys3\\Clarity\\report1.bat'>")
Response.Write("<PARAM NAME='RunParms' VALUE=''>")
Response.Write("<PARAM NAME='Display' VALUE=MAX'>")
Response.Write("</OBJECT>")
%>

<script>

function UpdateRec(theForm, rec) {

tmp_checked = 0;

tmp_login = theForm.login.value;
tmp_year = theForm.tmp_year.value;
tmp_quarter = theForm.tmp_quarter.value;
tmp_comm = theForm.comm.value;

if(theForm[rec].checked) {
tmp_checked = 1;
}

theForm.target = "MyFrame";
theForm.action = "qr_update.asp?axys=" + rec + "&tmp_quarter=" +
tmp_quarter + "&tmp_year=" + tmp_year + "&tmp_login=" + tmp_login +
"&tmp_checked=" + tmp_checked + "&tmp_comm=" + tmp_comm;
theForm.submit();
document.body.style.cursor = 'wait';
}

function GenerateReport(theForm, rec, do_checkbox) {

document.IntraLaunch.RunParms = rec;
IntraLaunch.ExecuteIt("Null");

if (do_checkbox) {
oldcomm = theForm.comm.value;
theForm.comm.value = "GSHOW";
theForm[rec].checked = true;
UpdateRec(theForm, rec);
theForm.comm.value = oldcomm;
}

tmp_year = theForm.tmp_year.value;
tmp_quarter = theForm.tmp_quarter.value;
theForm.target = "MyOtherFrame";
theForm.action = "generate.asp?quarter=" + tmp_quarter + "&year=" +
tmp_year + "&axys=" + rec;

var timer = setTimeout("document."+theForm.name+".submit()", 2000);
clearTimeout(timer);

//alert("GenerateReport form object name: " + theForm.name);
//document.updateform.submit();
}

background/explanation:

This is a task-status tracking web application. The purpose of this
code snippet is to automatically create two Axys reports as text
files, parse them into PDFs, and collate them into a third PDF, all on
the click of a button. GenerateReport is the method that's called
directly; the object declaration and UpdateRec are there for your
reference. The issue here is that it takes some time (a second or
two) to generate the text files via IntraLaunch, and I need to delay
the PDF operations (performed in generate.asp) until this is done.

The code itself is sound -- by uncommenting the last two lines,
everything functions smoothly, since the alert acts as a delay.

I have found that setTimeout is not executing the form submit at all:
I placed alerts in <body onload=> of both qr_update.asp and
generate.asp. The sans-setTimeout version pops an alert for each page,
but if I use setTimeout, I only get an alert for qr_update. I am
puzzled, though, because this seems to be the correct syntax for form
submission via setTimeout:
http://groups.google.com/[email protected]&rnum=10

Please help!

Thanks,
Michelle
 
L

Lee

Mic said:
var timer = setTimeout("document."+theForm.name+".submit()", 2000);
clearTimeout(timer);
Click to expand...

setTimeout doesn't insert a delay.
It schedules some task to be performed after a specified delay.
Execution proceeds immediately to the next line.

Those two lines say:
1. Wait two seconds, and then submit the form.
2. Nevermind.
 
T

Thomas 'PointedEars' Lahn

Lee said:
Mic said:

setTimeout doesn't insert a delay.
It schedules some task to be performed after a specified delay.
Click to expand...

Actually, if provided a string as first argument, setTimeout() schedules
that expression to be evaluated after a specified delay. If provided a
Function object reference instead, the function referred to is called,
using the third and following arguments of setTimeout() as arguments for
the function [JavaScript 1.2+/Gecko-DOM only; the IE-DOM does support
function references from v5.0 on, but not additional arguments to date
(IE 6.0 SP-1) -- setTimeout(alert, 2000, 42) yields an empty message box
in IE, but not in NN4+/Mozilla.]

However, the used expression is suboptimal as document.FormName is not a
standards compliant reference (i.e. not specified in W3C-DOM Level 1+).
Instead document.forms["FormName"] is specified there, thus the better
statement is either

var timer =
setTimeout("document.forms['"+theForm.name+"'].submit()", 2000);

or

var timer =
setTimeout(document.forms[theForm.name].submit, 2000);

Yet it would be much better to check (calling a user-defined method) if
there is document.forms[theForm.name].submit() before accessing it. For
the first variant, as used in a timeout, the pure, unchecked statement
is likely to fail if the window's content has changed in the meantime for
some reason. For the second variant, a part of the lookup path may be a
non-reference anyway, already causing a script error on assignment.
Therefore one should use

function submitForm(sFormName)
{
var f, t;
if (document
&& document.forms
&& (f = document.forms[sFormName])
&& ((t = typeof f.submit) == "function"
|| t == "object")
{
f.submit();
}
}

var timer = setTimeout("submitForm(" + theForm.name + ")", 2000);


PointedEars
 
L

Lasse Reichstein Nielsen

Thomas 'PointedEars' Lahn said:
var timer =
setTimeout(document.forms[theForm.name].submit, 2000);
Click to expand...

Does this work consistently? I can imagine implementations where
the submit function is the same for all forms, and relies on the
"this" reference to find out which form to submit. That would break
here because the function is called with the global object as "this".

I would write
setTimeout(function(){document.forms[theForm.name].submit();},2000);
to be safe, but I don't know if there is a browser where the former
version would break.

/L
 
T

Thomas 'PointedEars' Lahn

Lasse said:
Thomas 'PointedEars' Lahn said:
var timer =
setTimeout(document.forms[theForm.name].submit, 2000);
Click to expand...

Does this work consistently? I can imagine implementations where
the submit function is the same for all forms, and relies on the
"this" reference to find out which form to submit. That would break
here because the function is called with the global object as "this".

I would write
setTimeout(function(){document.forms[theForm.name].submit();},2000);
to be safe, but I don't know if there is a browser where the former
version would break.
Click to expand...

Sorry, I don't see why `this' in a submit() method called from
a global wrapper function is any different from the direct call.


PointedEars
 
T

Thomas 'PointedEars' Lahn

Lasse said:
Thomas 'PointedEars' Lahn said:
var timer = setTimeout(document.forms[theForm.name].submit, 2000);
Click to expand...

Does this work consistently?
Click to expand...

I'm pretty sure it does.
I can imagine implementations where the submit function is the same for
all forms, and relies on the "this" reference to find out which form to
submit. That would break here because the function is called with the
global object as "this".

I would write
setTimeout(function(){document.forms[theForm.name].submit();},2000); to
be safe, but I don't know if there is a browser where the former version
would break.
Click to expand...

Sorry, I fail to see the difference between the `this' reference in a
submit() method called from a global wrapper function in the global
execution context, and the `this' reference in a submit() method called
directly in the global execution context.


PointedEars
 
T

Thomas 'PointedEars' Lahn

Thomas said:
Lasse said:
Thomas 'PointedEars' Lahn said:
var timer = setTimeout(document.forms[theForm.name].submit, 2000);
Click to expand...

Does this work consistently?
I can imagine implementations where the submit function is the same for
all forms, and relies on the "this" reference to find out which form to
submit. That would break here because the function is called with the
global object as "this".

I would write
setTimeout(function(){document.forms[theForm.name].submit();},2000); to
be safe, but I don't know if there is a browser where the former version
would break.
Click to expand...

Sorry, I fail to see the difference between the `this' reference in a
submit() method called from a global wrapper function in the global
execution context, and the `this' reference in a submit() method called
directly in the global execution context.
Click to expand...

To clarify this: AIUI the above is semantically equivalent to

// The real constructor would be an internal implementation
// of W3C DOM's HTMLFormElement interface
function HTMLFormElement()
{
}

// By making submit() a prototype method (as it actually is),
// I have a "submit function [that] is the same for all forms
// and relies on the 'this' reference to find out which form
// to submit." as Lasse described.
HTMLFormElement.prototype.submit = function submit()
{
// The form is submitted here. I also return
// the `this' reference for test purposes.
return this;
}

// When the document is parsed, "form" elements
// are created as HTMLFormElement DOM objects
document.forms[theForm.name] = new HTMLFormElement;

// Retrieve a reference to the submit() method of that new object
// as the script engine does internally (see ECMAScript 3)
var theFormSubmit = document.forms[theForm.name].submit;

// I use the reference as argument for setTimeout
var timer = setTimeout(theFormSubmit, 2000);

setTimeout() is a method of the global object, so the object calling
theFormSubmit() is always the global object. The `this' reference
nevertheless refers to the respective HTMLFormElement object, no matter
if theFormSubmit() is called like the above (my solution) or in a wrapper
function (as Lasse's solution):

// The wrapper function that Lasse defined as anonymous;
// I use a named function to show the reference.
function lrnSubmitWrapper()
{
// I return the retrieved `this' reference for test purposes
return theFormSubmit();
}

// I use the reference to the wrapper function as argument;
// again: that's what the script engine does internally.
var timer = setTimeout(lrnSubmitWrapper, 2000);

That's quite easy to test:

alert(theFormSubmit() == lrnSubmitWrapper()); // true
alert(theFormSubmit() === lrnSubmitWrapper()); // true

AFAIS the only thing that differs here is the stack (trace).
Am I missing something?


PointedEars
 
M

Michael Winter

On Thu, 22 Apr 2004 18:00:06 +0200, Thomas 'PointedEars' Lahn

[snip]
Sorry, I fail to see the difference between the `this' reference in a
submit() method called from a global wrapper function in the global
execution context, and the `this' reference in a submit() method called
directly in the global execution context.
Click to expand...

It's a big one, as this snippet should show:

var obj = new ( function() {
var base = this;

this.method = function() {
alert( this == base );
};
});
var method = obj.method;

obj.method();
method();

In the first call, using a qualified reference, the this operator
correctly refers to the object, obj. In the second, unqualified call, the
this operator is not set as desired. It will, in fact, refer to the global
object. You would need to use call() to correctly apply the second
approach.

I learnt this in a similar way, using setTimeout() to directly call a
method.

Mike
 
T

Thomas 'PointedEars' Lahn

Please shorten your attribution.
[snip]
Sorry, I fail to see the difference between the `this' reference in a
submit() method called from a global wrapper function in the global
execution context, and the `this' reference in a submit() method called
directly in the global execution context.
Click to expand...

It's a big one, as this snippet should show:

var obj = new ( function() {
var base = this;

this.method = function() {
alert( this == base );
};
});
var method = obj.method;

obj.method();
method();
Click to expand...

I already know that. The discussion you snipped was about using a
wrapper function or not. Taking your example, my tests show that it
makes no difference to `this' if obj.method() is called directly or
via

function foo()
{
obj.method();
}

foo();

since the calling object is always `obj'.

BTW: Your From address violates Internet/NetNews standards.


PointedEars
 
R

Richard Cornford

Thomas said:
Thomas 'PointedEars' Lahn wrote:
Sorry, I fail to see the difference between the `this' reference in a
submit() method called from a global wrapper function in the global
execution context, and the `this' reference in a submit() method
called directly in the global execution context.
Click to expand...

To clarify this: AIUI the above is semantically equivalent to

// The real constructor would be an internal implementation
// of W3C DOM's HTMLFormElement interface
function HTMLFormElement()
{
}

// By making submit() a prototype method (as it actually is),
// I have a "submit function [that] is the same for all forms
// and relies on the 'this' reference to find out which form
// to submit." as Lasse described.
HTMLFormElement.prototype.submit = function submit()
{
// The form is submitted here. I also return
// the `this' reference for test purposes.
return this;
}

// When the document is parsed, "form" elements
// are created as HTMLFormElement DOM objects
document.forms[theForm.name] = new HTMLFormElement;

// Retrieve a reference to the submit() method of that new object
// as the script engine does internally (see ECMAScript 3)
var theFormSubmit = document.forms[theForm.name].submit;

// I use the reference as argument for setTimeout
var timer = setTimeout(theFormSubmit, 2000);

setTimeout() is a method of the global object, so the object calling
theFormSubmit() is always the global object. The `this' reference
nevertheless refers to the respective HTMLFormElement object, no
matter if theFormSubmit() is called like the above (my solution) or
in a wrapper function (as Lasse's solution):

// The wrapper function that Lasse defined as anonymous;
// I use a named function to show the reference.
function lrnSubmitWrapper()
{
// I return the retrieved `this' reference for test purposes
return theFormSubmit();
}

// I use the reference to the wrapper function as argument;
// again: that's what the script engine does internally.
var timer = setTimeout(lrnSubmitWrapper, 2000);

That's quite easy to test:

alert(theFormSubmit() == lrnSubmitWrapper()); // true
alert(theFormSubmit() === lrnSubmitWrapper()); // true

AFAIS the only thing that differs here is the stack (trace).
Am I missing something?
Click to expand...

Yes, your test is being skewed by assigning a reference to the function
object, that has been assigned to the prototype of HTMLFormElement, to a
global variable. The effect is that the function is called in the same
way in each context.

In Lasse's example the wrapper function took the form:-

function(){
document.forms[theForm.name].submit();
}

- Making it a - CallExpression -> MemberExpression Arguments - (with an
empty arguments list). MemberExpression evaluates to an internal
Reference type with - document.forms[theForm.name] - as its base object
and "submit" as its property name, when executed -
document.forms[theForm.name] - becomes the - this - object.

But in:-

function(){
return theFormSubmit();
}

The identifier - theFormSubmit - evaluates as a Reference type with the
global object as the base object and the property name "theFormSubmit".
So the - this - object for the execution of the function is the global
object (at least that is what the specs say should happen).

Unsurprisingly:-

| alert(theFormSubmit() == lrnSubmitWrapper()); // true
| alert(theFormSubmit() === lrnSubmitWrapper()); // true

- alerts true as the function is being executed with the - this -
reference set to the global object in both cases.

Personally I would expect the original:-

| setTimeout(document.forms[theForm.name].submit, 2000);

- to be problematic for exactly the reasons that Lasse did. Although the
MemberExpression - document.forms[theForm.name].submit - in the
arguments list for setTimeout will evaluate as a Reference type that
has - document.forms[theForm.name] - as its base object and the property
name "submit", the evaluation of the arguments list will call the
internal GetValue function, passing that Reference as an argument and
returning a value that is a function object. Any association with the -
document.forms[theForm.name] - object is lost at this point.

In principle, when setTimeout calls that function object it will be as a
property of the Activation object belonging to its execution context.
And step 7 in the Function Calls algorithm (section 11.2.3) requires
function properties of an Activation object to be called with a null -
this - value (which means the global object will be used in the pace of
null during the function call).

Richard.
 
Y

Yann-Erwan Perio

Some browsers, like Mozilla, implement host objects in a prototype-like
fashion; in this case, it is not unrealistic to consider there's a sort
of "this" value which is internally handled, and that the determination
of this "this" value follows the same rules as in javascript. Hence
Lasse's answer, which is exactly what should be done IMHO.
// Retrieve a reference to the submit() method of that new object
// as the script engine does internally (see ECMAScript 3)
var theFormSubmit = document.forms[theForm.name].submit;
Click to expand...

That's incorrect, you'd be getting the submit *function*, but the "this"
value would be the global object(see ECMAScript 3:)) - if the function
knows the "this" value, then that's an IE-like behavior, not a
javascript one.

var x="48";
var foo={bar:function(){alert(this.x)}, x:"42"};
var foobar=foo.bar;
foo.bar(); //42
foobar(); //48

setTimeout() is a method of the global object, so the object calling
theFormSubmit() is always the global object.
Click to expand...

That's probably true, still you simplify too much; as an argument of the
setTimeout function, the way theFormSubmit is called (that is, how its
scope chain is defined) depends on setTimeout implementation, not of
setTimeout "base object".

Still, what would you expect from:

var foo=1;
setTimeout("alert(this.foo)", 1);
setTimeout.apply({foo:2}, ["alert(this.foo)", 1]);
function lrnSubmitWrapper()
{
// I return the retrieved `this' reference for test purposes
return theFormSubmit();
Click to expand...

Nope, Lasse has fully qualified the submit method... Did you try your
example in Mozilla, or only IE;-)


HTH
Yep.
 
M

Michael Winter

Please shorten your attribution.
Click to expand...

You know I'm not going to, so there isn't much point in asking. :p

[snip]
I already know that.
Click to expand...

Probably, but if so, you're missing the point.
The discussion you snipped was about using a wrapper function or not.
Click to expand...

I knew precisely what your discussion was about, and my post addressed it.
Taking your example, my tests show that it makes no difference to
`this' if obj.method() is called directly or via

function foo()
{
obj.method();
}

foo();

since the calling object is always `obj'.
Click to expand...

I know, but that isn't the case when you omit the calling object, which is
effectively what happens when you pass setTimeout() a function reference.
This leads to it being called unqualified (that is, with "this" set to the
global object), which might lead to an error. Wrapping a qualified
reference in a globally defined function (or an anonymous one in this
case), avoids that. Replace

method();

with

setTimeout( obj.method, 1000 );

and you'll see that they're equivalent. Then perform

setTimeout( function() { obj.method(); }, 1000 );

and you'll see that it and

obj.method();

are equivalent.
BTW: Your From address violates Internet/NetNews standards.
Click to expand...

I know. You've already told me. However, people still e-mail me, so it
can't that big a deal.

Mike
 
L

Lasse Reichstein Nielsen

Thomas 'PointedEars' Lahn said:
// The wrapper function that Lasse defined as anonymous;
// I use a named function to show the reference.
function lrnSubmitWrapper()
{
// I return the retrieved `this' reference for test purposes
return theFormSubmit();
}
Click to expand...

That was not what I wrote. Rather, I called the function as a method
of an object.
// I use the reference to the wrapper function as argument;
// again: that's what the script engine does internally.
var timer = setTimeout(lrnSubmitWrapper, 2000);

That's quite easy to test:

alert(theFormSubmit() == lrnSubmitWrapper()); // true
alert(theFormSubmit() === lrnSubmitWrapper()); // true
Click to expand...

Yes, but also:
alert(theFormSubmit() == window); // true
AFAIS the only thing that differs here is the stack (trace).
Am I missing something?
Click to expand...

Yes, when a function is being called as a method and when it is being
called as a pure function.

Take this as a simple example:

<script type="text/javascript">
var foo = 42; // global variable
var obj = { foo : 37,
method : function() { alert(this.foo); } };

setTimeout(obj.method,1000);
setTimeout(function(){obj.method();},2000);
</script>

If the two approaches are equivalent, then the alerts should be the same.
They are not. The first is 42, showing that the method has lost its
association to "obj", while the second is 37.

The same can happen for form submits. Passing the form submit function
alone can leave a function that doesn't know which form to submit, while
passing the wrapped method call will always work.

/L
 
T

Thomas 'PointedEars' Lahn

Lasse said:
<script type="text/javascript">
var foo = 42; // global variable
var obj = { foo : 37,
method : function() { alert(this.foo); } };

setTimeout(obj.method,1000);
setTimeout(function(){obj.method();},2000);
</script>

If the two approaches are equivalent, then the alerts should be the same.
They are not. The first is 42, showing that the method has lost its
association to "obj", while the second is 37.
Click to expand...

I see. The first one is merely a reference to some Function
object from the view of the calling global/window object!
Thank you very much for your explanation.
The same can happen for form submits. Passing the form submit function
alone can leave a function that doesn't know which form to submit, while
passing the wrapped method call will always work.
Click to expand...

ACK, though I would prefer

setTimeout(function foo() { obj.method(); }, 2000);

for backwards compatibility.


PointedEars
 
D

Dr John Stockton

JRS: In article <[email protected]>, seen in
Thomas 'PointedEars' Lahn
BTW: Your From address violates Internet/NetNews standards.
Click to expand...

I doubt it. Please quote the standard to which you refer.

By the way, Hunnish attitudes went quite out of fashion after 1914-1918.

If Thomas Lahn is your real name, and if a potential employer should
search the Net for it, then ISTM that he/she will discover the
unattractiveness of your personality.
 
L

Lasse Reichstein Nielsen

Thomas 'PointedEars' Lahn said:
ACK, though I would prefer

setTimeout(function foo() { obj.method(); }, 2000);

for backwards compatibility.
Click to expand...

Depending on how much you care about backwarts compatability,
you might have to do:
setTimeout("global.path.to.obj.method()",2000);

I don't like writing code inside strings, for many of the same reasons
that I don't like using "eval", but IE 4 and NS 3 needs it.

Which browsers will not understand anonymous functions, but do
understand functional arguments to setTimeout? I don't know of any
on the Windows platform.

/L
 
O

optimistx

Dr said:
JRS: In article <[email protected]>, seen in
Thomas 'PointedEars' Lahn



I doubt it. Please quote the standard to which you refer.

By the way, Hunnish attitudes went quite out of fashion after 1914-1918.

If Thomas Lahn is your real name, and if a potential employer should
search the Net for it, then ISTM that he/she will discover the
unattractiveness of your personality.
Click to expand...
It is easier to tolerate and understand astonishing features, if one
puts e.g. an expression 'asperger syndrome' to google.com and reads some
key articles.

It helps me tolerate by imagining that my sick child would try to
continue his/her living here with the resources he/she has.
 
T

Thomas 'PointedEars' Lahn

| From: Michael Winter <[email protected]>
^^^^^^^^

[2004-04-24 17:47:26] pointedears:/var
$ chkmadd -v (e-mail address removed)
chkmadd 0.1.2.2004042206 -- (C) 2003, 2004 Thomas Lahn <[email protected]>
Distributed under the terms of the GNU General Public License (GPL).
See COPYING file or <http://www.fsf.org/copyleft/gpl.html> for details.
Report bugs to <[email protected]>.

E-mail address(es) to check:
(e-mail address removed)

Verifying <[email protected]> ...
Mail exchanger(s) for blueyonder.co.invalid:
None.
Mail exchanger(s) for co.invalid:
None, thus <[email protected]>
is definitely not an e-mail address (no MX).

---------------------
Network Working Group D. Eastlake
Request for Comments: 2606 A. Panitz
BCP: 32 June 1999
Category: Best Current Practice

Reserved Top Level DNS Names

[...]

Abstract

To reduce the likelihood of conflict and confusion, a few top level
^^^^^^^^^^^^^^^
domain names are reserved for use in private testing, as examples in
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
documentation, and the like. In addition, a few second level domain
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
names reserved for use as examples are documented.

[...]

2. TLDs for Testing, & Documentation Examples
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
There is a need for top level domain (TLD) names that can be used for
creating names which, without fear of conflicts with current or
future actual TLD names in the global DNS, can be used for private
^^^^^^^^^^^^^^^^^^^^^^^
testing of existing DNS related code, examples in documentation, DNS
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
related experimentation, invalid DNS names, or other similar uses.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

For example, without guidance, a site might set up some local
additional unused top level domains for testing of its local DNS code
and configuration. Later, these TLDs might come into actual use on
the global Internet. As a result, local attempts to reference the
real data in these zones could be thwarted by the local test
versions. Or test or example code might be written that accesses a
TLD that is in use with the thought that the test code would only be
run in a restricted testbed net or the example never actually run.
Later, the test code could escape from the testbed or the example be
actually coded and run on the Internet. Depending on the nature of
the test or example, it might be best for it to be referencing a TLD
permanently reserved for such purposes.

To safely satisfy these needs, four domain names are reserved as
listed and described below.

.test
.example
.invalid
.localhost

[...]

".invalid" is intended for use in online construction of domain
names that are sure to be invalid and which it is obvious at a
glance are invalid.

[...]

---------------------
Network Working Group P. Resnick, Editor
Request for Comments: 2822 QUALCOMM Incorporated
Obsoletes: 822 April 2001
Category: Standards Track

Internet Message Format

[...]

3.6.2. Originator fields

The originator fields of a message consist of the from field, the
sender field (when applicable), and optionally the reply-to field.
The from field consists of the field name "From" and a
comma-separated list of one or more mailbox specifications. If the
from field contains more than one mailbox specification in the
mailbox-list, then the sender field, containing the field name
"Sender" and a single mailbox specification, MUST appear in the
message. In either case, an optional reply-to field MAY also be
included, which contains the field name "Reply-To" and a
comma-separated list of one or more addresses.

from = "From:" mailbox-list CRLF

[...]


3.4. Address Specification

Addresses occur in several message header fields to indicate senders
and recipients of messages. An address may either be an individual
mailbox, or a group of mailboxes.

[...]

mailbox = name-addr / addr-spec

name-addr = [display-name] angle-addr

name-addr = [display-name] angle-addr

angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr

[...]

A mailbox receives mail. [...]
^^^^^^^^^^^^^^^^^^^^^^^^
---------------------

A good informal explanation why such address munging is a Bad Thing[1]:

<http://www.interhack.net/pubs/munging-harmful/>


HTH & HAND

PointedEars
___________
[1] http://catb.org/~esr/jargon/html/B/Bad-Thing.html
 
D

Dr John Stockton

JRS: In article <[email protected]>, seen in
Thomas 'PointedEars' Lahn
Network Working Group D. Eastlake
Request for Comments: 2606 A. Panitz
BCP: 32 June 1999
Category: Best Current Practice
Click to expand...
To reduce the likelihood of conflict and confusion, a few top level
^^^^^^^^^^^^^^^
domain names are reserved for use in private testing, as examples in
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
documentation, and the like.
Click to expand...


Note - "and the like".

".invalid" is intended for use in online construction of domain
names that are sure to be invalid and which it is obvious at a
glance are invalid.
Click to expand...


The TLD having been declared unusable for cross-net communication, it is
entirely reasonable to use it for non-communication.

Circumstances have changed since the time when it was not felt necessary
for that document to deal with anti-spam precautions, so nothing can be
read into the omission in respect to present-day usage.

Grow up. Remember what happened to Benito - according to Niven &
Pournelle, he eventually reaped the reward of honourable behaviour.
 

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

Similar Threads

HCaptcha - How to stop page from refreshing on submit if captcha is not checked/validated 1
Why is this WordPress comments form not submitting? 1
Automatically submit form after selection 8
Issue with passing fetched data to POST form. How can I? 0
Script to send email not working 1
Hey can anyone tell me why input data wont save in my database? 0
submit form with javascript 3
newbie Javascript checked is null or not an object 6

Members online

No members online now.
Total: 119 (members: 0, guests: 119)
Robots: 324

Forum statistics

Threads
473,888
Messages
2,569,964
Members
46,293
Latest member
BonnieHamb

Latest Threads

Top