In a <form> element, can you have more than one action attribute?

Question: In a <form> element, can you have more than one action=" " attribute?


<form action="somepage_1.php, somepage_2.html" method="POST">
   <section class="login">
     <label for="user_name">Log In</label>
     <input type="text" name="user_name" id="user_name">
     <label for="pass-wd">Password</label>
     <input type="password" name="pass-wd" id="pass-wd">

Why you may ask?

  • I was trying to process how the form would validate the end_user and then redirect him or her based on validating the login and password. (Note: This is just an example. The thought is for any situation that requires multiple actions to take place.)

  • If the ‘action’ attribute determines where the information is sent and the ‘name’ attribute passes value when sent. What happens if I need the data to be checked in a database like SQL through somepage_1.php. Then redirect him to said page somepage_2.html.

  • Or what if I would like to store that data else where while redirecting end_user to another page?

If I’m only able to provide one (action=" ") then how do I get to step two? Which is sending end_user to somepage_2.html if I already directed the form to got to somepage_1.php?

Only one handler per request. That is the norm. Nothing precludes the handler from chaining to another handler, server-side, but that is another discussion. What would be the real need for two handlers?

1 Like

Thank you,

My original thought process was once the submit button is clicked the action attribute takes the name attribute and stores it in the document selected for the action attribute. Which then can be called by using the name attribute’s description.

File: ./somepage_1.htmtl

Form: action=“somepage_2.html”
Value: name=“somedata”

File from action: ./somepage_2.html
Call ID: id=“somedata”
Value: is the value sent from previous page name=“somedata”

Is this correct?

Your Question
What would be the real need for two handlers?

My Answer
Handler 1: To store data on a master sheet or database with data submitted.
Handler 2: To redirect user to new page with data submitted.

New Question to Your Answer
How is the server processing the information?
Does the information goto where I originally asked it to go in this case somepage_2.html?

If so
How do I show the value that was submitted to somepage_2.html?

That would be server side, so still only one handler for the form POSTDATA.

Not so. The action attribute contains a URL of the server-side resource that will handle the POSTDATA. The form data is composed in the request header (POST) or the query string (GET). The handler then parses the data from the header and hands it off to be sanitized before being added to the database or used in some form of server-side query such as snippets to be composed and sent back as a response to the form submission.

1 Like


So before it is seen it must go through another process to tell the server what to do with the information?

It is assumed the server-side resource is equipped to handle the request from the form action. The browser knows how to compose the request header from a form submission. It pairs up all the name attributes with their corresponding value attributes.

<input name="username">
<input name="password">

In the header,

1 Like

What if you told the server to process the information on another html page? Instead of using php or java doc? Will the server post the data submitted in html format? Or do you have to provide the ID to make this work?

The handler will also have built verification and sanitizing to prevent injection of code through a form element. Everything is stripped that doesn’t look like plain text.

Very often the resource that is requested in the action attribute IS the page that will be sent back once all the above tasks have been performed. The PHP script is written into the server-side page and generates the response document.

The response document will be a static HTML page such as a ‘Data Submitted’ message that appears for maybe thirty seconds. A message would state that the page will be redirected in said amount of time. That page would have a redirect written in the meta data section (the HEAD). See, page redirection for more details on that process. There is your second HTML page, though.

1 Like

My Final Thoughts

Learning how to create a form in HTML is great! For those that are viewing this post and want to understand how to make the form work, you will need to dive deeper into server-side programming to package your idea together.

Anyone of these languages would be a good start:
PHP, Perl, Java, .Net, Ruby, etc…

However, I did not include validation in this topic because my idea was to create two processes with one action once the submit button was clicked. Validation would be another topic. So I did not want to confuse anyone else that ran into the same question I did.

The solution to my original question was answered by @mtf:

Nothing precludes the handler from chaining to another handler, server-side, but that is another discussion.

I did not find that to be the solution at first because there was not enough info for me to go on at first. Frankly because I did not understand the process. After further questioning, I came to realize that you need a server-side doc to process the information and then tell it what to do.

I want to thank @mtf for his follow-up answers and being prompt!

Hope this post helps someone else!

1 Like

You’re welcome, @triton-svi.

We can do some client-side validation in sync with the user filling the form. See onchange event for more details. We wouldn’t want to give up too much information so client-side validation should look for things like empty fields, wrong data type, incorrect email format, incorrect telephone, incorrect postal code or zip, and so on. There won’t be anything too revealing in that type of validation.

If we have other types of processing (AJAX, for instance) that can only be done when the form is submitted, then we would need an onsubmit event listener/handler that prevents the default action and lets our script run its course in composing the JSON for an XHR, or some such pre-request preparation. This is a bit more complicated, obviously but will surface in time as you dive deeper into JS interaction with the server.