HTML forms - difference between 'action' and the 'next' variable? - html

According to the HTML book which I am reading (and according to here: http://www.w3schools.com/tags/att_form_action.asp) it says that in the case of forms:
<form action="/login/" method="post">
'action' specifies where to send the form data when a form is submitted. The syntax for it could be
<form action="URL">
Now, in the book I am reading, it also talks about a hidden 'next' variable, like so:
<form action="/login/" method="post">
<input type='hidden' name='next' value='/' />
<input type='submit' value='login' />
The book I am reading states that
The form contains a submit button as well as a hidden field called 'next'. This hidden variable contains a URL that tells where to redirect the user after they have logged in.
From my understanding, doesn't 'action' either way tell specify where to redirect to after the form has been submitted? So isn't having the hidden 'next' variable not necessary because 'action' already tells where to redirect to? Which takes priority if action and next are different URLs? Does it redirect to the URL in action or the URL in next?

First up the action attribute has nothing to do with redirection.
When you click a submit button in a form the browser sends an HTTP request to the server, specificaly to the resource mentioned in the action attribute, using either get or post. What happens next is entirely dependant on what you are using server side.
As far as I am aware the presense of a Next property in the request has no special meaning.
Normally when a form is submitted one of two things will happen
The server does some process then return an HTTP Response. This will show the action url in the address bar of the browser
The server does some processing then redirects the user to a new page. This is usualy programmed by you the programmer and does not happen automagicaly. In php you would use http_redirect(someURL). The next hidden field could be used to hold this URL but it won't do anything with it by itself.
On a technical note, http redirects, be they with asp, php, etc cause, an additional round trip to the browser. So in the case of the redirect above, an HTTP Response is send to the broswser with a header indicating to redirect and where to direct to. The browser will then send a new request to the new location. This is why the new address appears in the browser address bar.

Action url is where the page will be redirected to, by default. The value of next has no effect unless you have server side code to do that. Even if you do write code, the redirect will first go to action url and then to any other url you have changed.

Related

Trying to open a page after submit in a form

I'm trying to add a confirmation page after a submit on a form but i can't figure out why it doesnt work.
I'm working on Prestashop and my action look like that :
<form action="{$urls.pages.contact}" method="post" {if $contact.allow_file_upload}enctype="multipart/form-data"{/if}>
i tried differents things like target="_blank" or action="website.com & {$urls.pages.contact}"
The "action" tag of a form value is the URL where the values of post request are sent. It means that you should have a controller+method which must intercept and process those values at this address (URL, route, call it as you want).
Its not mandatory to do it this way since you can send your data with Ajax, but it's not what you want.
A proper way to do what you want is to set the "action" as a route which refers to a controller::method which process your Post data, then redirect to a page with the Tools::redirect() method.

What happens when submitting an html form? (the process behind the scenes)

Can someone please tell me what happens behind the scenes in the following case (i.e. explain the whole technical process)?
<form method="get" action="#">
<input type="text" name="d" value="flowers">
<button type="submit">send</button>
</form>
In this case after one has clicks on “send” a new webpage opens saying: "You have searched for "flowers" " and an image of some flowers below.
In the browser tab right after the URL of the newly opened page there is
“/?s=flowers”. What is that?
Thank you in advance for your answers!
When you click Send, the page data specified in the form information and values is passed to the server via HTTP.
The /?s=flowers is the GET data being passed back to the server. Although, based on the form code you've provided, the "name" of that value is d. So the URL would actually have /?d=flowers
The PHP or server side language then handles that information to do specific tasks. It can access the info using the name "d". This method of sending data is called GET, there are also other ways of doing this. The most common, POST, does not display the data in the URL and send the data through HTTP headers.
The code you've shown has an action of "#" which means the HTTP method is being sent the same page. Meaning this page code would have some PHP located in it. This can also be done by using a seperate file, such as action='send.php'

Focus on footer form with hash/fragment keeps hash after successful submit

I have a form at the bottom of the page. It's a normal form. I've set the action to #adding-show and the form's id is "form". The result is that the form submits to the current page (the browser doesn't send #adding-show to the server).
If the submission is invalid/fails, the form is focused and visible = good.
If the submission is valid, the server redirects the browser to the same page (to get rid of the postback), without hash, but the browser 'remembers' the hash, so the browser redirects to #adding-show at the bottom of the page.
In short: keeping the hash is good when submission is invalid/fails, but the hash shouldn't be used if submission succeeded.
The question: is there a way to do that? Redirect correctly and 'forget' the hash appropriately. Some JS is okay. I can make the server do anything.
If you like code, it's on Github.
Or:
<form id="adding-show" method="post" action="#adding-show">
I've solved it with a piece of 'conditional' JS: https://github.com/rudiedirkx/series/blob/83c74f183d4c10474e2b92d819349120ad0094b6/index.php#L627 It's only printed if the page is in postback, so the form needs to be highlighted.

Form not submitting programmatically

The form here works fine in the browser, but for some reason I cannot submit it programmatically.
If I do not enter anything in the form in the browser then when I submit I get a 'Log-In Error'. But If I try sending a POST request to the form action url (with and without parameters) the response is the same page. Why is this?
You probably aren't accounting for all of the <input /> fields. When serializing the form, I get this list of parameters:
__EVENTTARGET=
__EVENTARGUMENT=
__VIEWSTATE=
UserLoginControl%24districtId=
UserLoginControl%24districtName=
UserLoginControl%24UserName=
UserLoginControl%24UserPassword=
UserLoginControl%24district=
districtId=
districtName=
ScreenWidth=
ScreenHeight=
FlashPlayerVersion=
Make sure you set all of them (or guess and check which ones don't mean anything).

Is there a way to ignore form response?

Is there a way to specify a form either through type or action url to not open the response? In other words I would like to send the info to the server, but not do anything on the client. I know I can use ajax and ignore the response, but I would like to avoid adding all the js to my code if possible.
Edit: I didn't mean to limit myself to the html form. In my case server side solutions were also acceptable.
Have the server return HTTP 204 (No Content) after the form submission. According to the HTTP 1.1 spec:
10.2.5 204 No Content
The server has fulfilled the request
but does not need to return an
entity-body, and might want to return
updated metainformation. The response
MAY include new or updated
metainformation in the form of
entity-headers, which if present
SHOULD be associated with the
requested variant.
If the client is a user agent, it
SHOULD NOT change its document view
from that which caused the request to
be sent. This response is primarily
intended to allow input for actions to
take place without causing a change to
the user agent's active document view,
although any new or updated
metainformation SHOULD be applied to
the document currently in the user
agent's active view.
The 204 response MUST NOT include a
message-body, and thus is always
terminated by the first empty line
after the header fields.
This sounds like exactly what you want.
try this:
<iframe id="invisible" ...
<form target="invisible" ...
I found that name attribute should be specified as well (I tested in IE11). E.g:
<iframe id="invisible" name="invisible" style="display:none;"></iframe>
<form method="post" target="invisible" action="url.com/whatever?x=y" id="fileForm" enctype="multipart/form-data">
With ASP.NET you could have a page that processes the form post and simply end the response right away, this will leave the user at the same page.
However, no response to the user at all is not the best user experience.....