FORM and javascript.location

**Evertjan.** · Sep 9 '06, 12:05 PM

Re: FORM and javascript.loca tion

wrote on 09 sep 2006 in microsoft.publi c.inetserver.as p.general:

I am using an asp page in which i dynamically fill the ACTION property
of the form. The problem is that whenever i try to redirect to a html
page using the javascript:loca tion, it is getting redirected to the
location in the ACTION attribute of the form element despite what is
assigned to the location attribute of the javascript.

yes, but not as you showed, only if the button element is inside(!!!) the
form, the submit could fire first

>
<FORM NAME="CRYSTFORM " METHOD=POST ACTION=<%=thisP age%>>

use clientside quotes for the case that there is a space in the thispage
value. use single quptes clientside for clarity.

Try:

<form name = 'crystform' method = 'post' action = '<% = thispage %>'>

:
:
:
>
</FORM>
>
>
<button onClick ="javascript:lo cation='<%=goBa ckToURL%>'";id= button1
name=button1OK </button>

do not use a ; outside the javascript string

onClick expects javascript [if no clientsided vbs is used],
so do not add the Javascript: part.

Try adding type='button' if inside a form.

<button type='button'
onClick ="location.href ='<%=goBackToUR L%>';"
id='button1'
name='button1'>
go back
</button>

I am using div tags in middle of the form to control the visibility of
certain visual elements.

not related to your problem, John.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

**Dave Anderson** · Sep 9 '06, 02:55 PM

Re: FORM and javascript.loca tion

johnemmatty@gma il.com wrote:

I am using an asp page in which i dynamically fill the ACTION property
of the form. The problem is that whenever i try to redirect to a html
page using the javascript:loca tion, it is getting redirected to the
location in the ACTION attribute of the form element despite what is
assigned to the location attribute of the javascript.
>
<FORM NAME="CRYSTFORM " METHOD=POST ACTION=<%=thisP age%>>

>>
>>
>>

>
</FORM>
>
>
<button onClick ="javascript:lo cation='<%=goBa ckToURL%>'";id= button1
name=button1OK </button>

I would start by getting out of the habit of using the javascript:
pseudo-protocol. The HTML specification requires the browser to hand the
contents of ONCLICK attributes to a scripting engine:

onclick = script [CT]

Scripts in HTML documents

http://www.w3.org/TR/html4/interact/scripts.html#adef-onclick

....and...

User agents must not evaluate script data as HTML markup but
instead must pass it on as data to a script engine.

Basic HTML data types

http://www.w3.org/TR/html4/types.html#type-script

In my opinion, if you are using the javascript: pseudo-protocol, you are
doing something wrong. More here: http://jibbering.com/faq/#FAQ4_24

But the real issue is that you did not realize that by default, the BUTTON
element is the same as an INPUT TYPE="submit":

17.5 The BUTTON element
type = submit|button|r eset [CI]
This attribute declares the type of the button.
Possible values:
* submit: Creates a submit button. This is the
default value.
* reset: Creates a reset button.
* button: Creates a push button.

Forms in HTML documents

http://www.w3.org/TR/html4/interact/forms.html#edef-BUTTON

Solutions include:

- Use the TYPE="button" attribute
- Cancel the action of the form by preventing
the click action from propogating:
onclick="locati on='<%=goBackTo URL%>';return false"
- Change to INPUT TYPE="button"
- Use an anchor: <a href="<%=goBack ToURL%>">

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.

**johnemmatty@gmail.com** · Sep 11 '06, 04:45 AM

Re: FORM and javascript.loca tion

Thanks to everyone replied to my query... especially to Evertjan, your
post helped me to solve my problem. Dave Anderson.. your post was
resourceful and served me to acquire new informations,an d i really
really liked your signature.

Thanks,
John.
Dave Anderson wrote:

johnemmatty@gma il.com wrote:

I am using an asp page in which i dynamically fill the ACTION property
of the form. The problem is that whenever i try to redirect to a html
page using the javascript:loca tion, it is getting redirected to the
location in the ACTION attribute of the form element despite what is
assigned to the location attribute of the javascript.

<FORM NAME="CRYSTFORM " METHOD=POST ACTION=<%=thisP age%>>

>
>
>

</FORM>

<button onClick ="javascript:lo cation='<%=goBa ckToURL%>'";id= button1
name=button1OK </button>

>
I would start by getting out of the habit of using the javascript:
pseudo-protocol. The HTML specification requires the browser to hand the
contents of ONCLICK attributes to a scripting engine:
>
onclick = script [CT]

Scripts in HTML documents

http://www.w3.org/TR/html4/interact/scripts.html#adef-onclick

>
...and...
>
User agents must not evaluate script data as HTML markup but
instead must pass it on as data to a script engine.

Basic HTML data types

http://www.w3.org/TR/html4/types.html#type-script

>
In my opinion, if you are using the javascript: pseudo-protocol, you are
doing something wrong. More here: http://jibbering.com/faq/#FAQ4_24
>
But the real issue is that you did not realize that by default, the BUTTON
element is the same as an INPUT TYPE="submit":
>
17.5 The BUTTON element
type = submit|button|r eset [CI]
This attribute declares the type of the button.
Possible values:
* submit: Creates a submit button. This is the
default value.
* reset: Creates a reset button.
* button: Creates a push button.
>

Forms in HTML documents

http://www.w3.org/TR/html4/interact/forms.html#edef-BUTTON

>
Solutions include:
>
- Use the TYPE="button" attribute
- Cancel the action of the form by preventing
the click action from propogating:
onclick="locati on='<%=goBackTo URL%>';return false"
- Change to INPUT TYPE="button"
- Use an anchor: <a href="<%=goBack ToURL%>">
>
>
--
Dave Anderson
>
Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.

**Dave Anderson** · Sep 11 '06, 04:15 PM

Re: FORM and javascript.loca tion

Evertjan. wrote:

use clientside quotes for the case that there is a space
in the thispage value. use single quptes clientside for
clarity.
>
<form name = 'crystform' method = 'post' action = '<% = thispage %>'>

And if the value contains single quotes, Evertjan?

I think this is poor advice. Double quotes plus Server.HTMLEnco de() is the
proper way to inject data into attributes:

<form action="<%=Serv er.HTMLEncode(t hispage)%>" ...>

I also think your argument for clarity lacks merit, but that is a matter of
taste, I suppose.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.

**Evertjan.** · Sep 11 '06, 05:15 PM

Re: FORM and javascript.loca tion

Dave Anderson wrote on 11 sep 2006 in
microsoft.publi c.inetserver.as p.general:

Evertjan. wrote:

>use clientside quotes for the case that there is a space
>in the thispage value. use single quptes clientside for
>clarity.
>>
><form name = 'crystform' method = 'post' action = '<% = thispage %>'>

>
And if the value contains single quotes, Evertjan?
>
I think this is poor advice. Double quotes plus Server.HTMLEnco de() is
the proper way to inject data into attributes:
>
<form action="<%=Serv er.HTMLEncode(t hispage)%>" ...>

Wouldn't that encode single quote/apostophe just as well?

I also think your argument for clarity lacks merit, but that is a
matter of taste, I suppose.

I always, well if possible, enclose clientside strings in single quotes in
a mixed, that is clientside and serverside code, environment.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

**Dave Anderson** · Sep 11 '06, 05:35 PM

Re: FORM and javascript.loca tion

Evertjan. wrote:

> <form action="<%=Serv er.HTMLEncode(t hispage)%>" ...>

>
Wouldn't that encode single quote/apostophe just as well?

You should already know that it does not. What would it encode to? There is
a character entity defined for double quote ("). There is not one for
apostrophe.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.

**Evertjan.** · Sep 11 '06, 05:45 PM

Re: FORM and javascript.loca tion

Dave Anderson wrote on 11 sep 2006 in
microsoft.publi c.inetserver.as p.general:

Evertjan. wrote:

>> <form action="<%=Serv er.HTMLEncode(t hispage)%>" ...>

>>
>Wouldn't that encode single quote/apostophe just as well?

>
You should already know that it does not. What would it encode to?
There is a character entity defined for double quote ("). There
is not one for apostrophe.

Why do you expect things of me?

I never use[d] Server.HTMLEnco de().

I never put any quotes in an URL,
and try not to have spaces in them, but that happens now and again.
I don't write <form>s to external URLs, only to my own,
and I master my own URL naming.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

**Dave Anderson** · Sep 11 '06, 06:45 PM

Re: FORM and javascript.loca tion

Evertjan. wrote:

Why do you expect things of me?

Because you offer advice.

I never use[d] Server.HTMLEnco de().

That's a shame. Most of my forms post back to themselves, which leads to the
inevitable:

<input name="xxx" value="<%=xxx%> ">

....where xxx is Server.HTMLEnco de(Request.Form ("xxx").Item ).

Without HTMLEncode, how do you deal with arbitrary markup, Evertjan? Do you
really want to inject a value like ["><input name="yyy" ...>< "] into your
document?

I never put any quotes in an URL, and try not to have
spaces in them, but that happens now and again.
I don't write <form>s to external URLs, only to my own,
and I master my own URL naming.

This is not about URLs. My comments are directed at your "use single quotes"
advice. Filling an HTML attribute with arbitrary data is among the various
reasons why that advice is anti-useful.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.

**johnemmatty@gmail.com** · Sep 12 '06, 06:55 AM

Re: FORM and javascript.loca tion

The problem is back..........i n mozilla firefox 1.7.12..HA..HA. It was
ok with 1.5.0.6.

Dave Anderson wrote:

Evertjan. wrote:

Why do you expect things of me?

>
Because you offer advice.
>
>
>

I never use[d] Server.HTMLEnco de().

>
That's a shame. Most of my forms post back to themselves, which leads to the
inevitable:
>
<input name="xxx" value="<%=xxx%> ">
>
...where xxx is Server.HTMLEnco de(Request.Form ("xxx").Item ).
>
Without HTMLEncode, how do you deal with arbitrary markup, Evertjan? Do you
really want to inject a value like ["><input name="yyy" ...>< "] into your
document?
>
>
>

I never put any quotes in an URL, and try not to have
spaces in them, but that happens now and again.
I don't write <form>s to external URLs, only to my own,
and I master my own URL naming.

>
This is not about URLs. My comments are directed at your "use single quotes"
advice. Filling an HTML attribute with arbitrary data is among the various
reasons why that advice is anti-useful.
>
>
>
--
Dave Anderson
>
Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.

**Evertjan.** · Sep 12 '06, 07:05 AM

Re: FORM and javascript.loca tion

Dave Anderson wrote on 11 sep 2006 in
microsoft.publi c.inetserver.as p.general:

Evertjan. wrote:

>Why do you expect things of me?

>
Because you offer advice.
>

>I never use[d] Server.HTMLEnco de().

>
That's a shame. Most of my forms post back to themselves, which leads
to the inevitable:
>
<input name="xxx" value="<%=xxx%> ">

That is different, I thought we were talking

<form action=...

so about url's

...where xxx is Server.HTMLEnco de(Request.Form ("xxx").Item ).
>
Without HTMLEncode, how do you deal with arbitrary markup, Evertjan?
Do you really want to inject a value like ["><input name="yyy" ...><
"] into your document?

I never deal with arbitrary strings [why do you call it markup?]

I always validate to my liking, which often involves preparing for database
input

>I never put any quotes in an URL, and try not to have
>spaces in them, but that happens now and again.
>I don't write <form>s to external URLs, only to my own,
>and I master my own URL naming.

>
This is not about URLs. My comments are directed at your "use single
quotes" advice. Filling an HTML attribute with arbitrary data is among
the various reasons why that advice is anti-useful.

I stand by the my of single quites in always html and in javascript
whenever not impractical.

I never allow arbitrary data, and I would suggest to anyone not to do that.
Input data should be tested and either converted or rejected at the start,
which is IMHO a reasonable burden to the user.

I think the use of Server.HTMLEnco de() is a nice way, but if it does not
convert the apostrofe, not a good one for my standards.

The use of " and %24,etc are a nucance anyway, because they alter the
length of a string, and get you into unforseen behavour with string
manipulation, be it old and trusted mid() or regex.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

**Dave Anderson** · Sep 12 '06, 12:35 PM

Re: FORM and javascript.loca tion

[please do not toppost]

johnemmatty@gma il.com wrote:

The problem is back..........i n mozilla firefox 1.7.12..HA..HA.
It was ok with 1.5.0.6.

What on earth are you talking about?

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.

**Dave Anderson** · Sep 12 '06, 12:55 PM

Re: FORM and javascript.loca tion

Evertjan. wrote:

>Without HTMLEncode, how do you deal with arbitrary markup,
>Evertjan? Do you really want to inject a value like

["><input name="yyy" ...>< "] into your document?
>
I never deal with arbitrary strings [why do you call it markup?]

If you use text inputs or textareas, you deal with arbitrary strings.

Why do I call markup submitted as input values markup? Gee, I don't know...

I never allow arbitrary data, and I would suggest to anyone
not to do that. Input data should be tested and either
converted or rejected at the start, which is IMHO a
reasonable burden to the user.

I always allow free-form data in textareas, since I cannot rule out the
legitimate need for a specific character. There is *nothing* difficult about
it.

I think the use of Server.HTMLEnco de() is a nice way, but
if it does not convert the apostrofe, not a good one for my
standards.

You do realize that this makes my point for me, don't you?

The use of " and %24,etc are a nucance anyway, because
they alter the length of a string, and get you into unforseen
behavour with string manipulation, be it old and trusted
mid() or regex.

This is ridiculous, so let me ridicule it:

(1) %24 does not result from Server.HTMLEnco de(). It is
not a character entity. You could confirm this easily:
Response.Write( "%24") // output: %24

(2) The browser does not care about the string length. Or
were you under the mistaken impression that I was
advocating the use of HTMLEncode for anything other
than injection into the Response stream? I don't know
where you could have gotten that idea, since all of my
examples used it properly.

(3) Mid() and RegEx are more work for you and no less work
for the server than HTMLEncode(), and they do not
preserve the user input. That's really a sad approach
to take.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.

**Evertjan.** · Sep 12 '06, 01:05 PM

Re: FORM and javascript.loca tion

Dave Anderson wrote on 12 sep 2006 in
microsoft.publi c.inetserver.as p.general:

Evertjan. wrote:

>>Without HTMLEncode, how do you deal with arbitrary markup,
>>Evertjan? Do you really want to inject a value like

>["><input name="yyy" ...>< "] into your document?
>>
>I never deal with arbitrary strings [why do you call it markup?]

>
If you use text inputs or textareas, you deal with arbitrary strings.
>
Why do I call markup submitted as input values markup? Gee, I don't
know...
>
>
>

>I never allow arbitrary data, and I would suggest to anyone
>not to do that. Input data should be tested and either
>converted or rejected at the start, which is IMHO a
>reasonable burden to the user.

>
I always allow free-form data in textareas, since I cannot rule out
the legitimate need for a specific character. There is *nothing*
difficult about it.
>
>
>

>I think the use of Server.HTMLEnco de() is a nice way, but
>if it does not convert the apostrofe, not a good one for my
>standards.

>
You do realize that this makes my point for me, don't you?
>
>
>

>The use of " and %24,etc are a nucance anyway, because
>they alter the length of a string, and get you into unforseen
>behavour with string manipulation, be it old and trusted
>mid() or regex.

>
This is ridiculous, so let me ridicule it:
>
(1) %24 does not result from Server.HTMLEnco de(). It is
not a character entity. You could confirm this easily:
Response.Write( "%24") // output: %24
>
(2) The browser does not care about the string length. Or
were you under the mistaken impression that I was
advocating the use of HTMLEncode for anything other
than injection into the Response stream? I don't know
where you could have gotten that idea, since all of my
examples used it properly.
>
(3) Mid() and RegEx are more work for you and no less work
for the server than HTMLEncode(), and they do not
preserve the user input. That's really a sad approach
to take.

As you seem intent to prove your point, not that your idea is better,
which I think is acceptable, but to use totally irrelevant comments on my
words, will stop responding.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

FORM and javascript.location

FORM and javascript.location

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment