Welcome to Exploring Computing.
Today's video is Creating Webpages, Forms--
Get Versus Post.
So if you've seen the forms videos,
we've talked about how to create a form on a web page
and use it to create some elements that
allow the user to enter information into the web page
and submit it to the web server.
I mentioned that there are a number of different attribute
value pairs that can go on the form.
And one of them is the action.
The action is going to determine what
actually happens on the server when the user submits
the information.
And so, typically, this is going to be
the URL of the location of the program, which
will respond when the user submits
the information in the form.
So in this particular case, I'm using a relative reference,
example.php.
And so this means that there's a PHP
program sitting on the server.
And the name of that PHP program is an example of that PHP.
And it's located in the exact same location as the HTML file
that has this form on here.
If you're not actually working with a program on the server,
you actually do have some options.
So you can use a mailto URL.
And if the user has their web browser set up
to interact with their email system,
this would actually email the information in the form to you.
Stanford also has their own special setups
that can get that information from a form sent
to you without actually doing any programming on your own.
But for now, we're going to take a look at what actually happens
when we're working with a form and the user is actually
submitting information to the server.
That's the most common case.
So that's the action.
But there's also this method list here.
And this turns out to be quite important.
When you're actually trying to set up
a form for actual interaction with a real web server,
it's very important that you get the setting right.
It also has a number of implications
in terms of when the users interact with the form.
And I think you'll discover when we talk about this that you
have run into these situations before
and maybe wondered why the computer is doing
certain things in some cases with the form
and other things in other cases with the form.
And it turns out that this setting
has some very visible effects to the user of the web page.
Basically, what the method controls
is how the information is sent to the web server.
This has important implications for bookmarking and emailing
web pages.
So if you've ever tried to email a friend the results
of a search and they weren't able to actually get
those results, what was going on was the Post versus Get here.
And it also has implications in terms of
whether or not the state of the server
is changed by the submission of the form.
So let's go ahead and take a look at this first part
here, how the information is being
sent to the server and the side effect
on bookmarking or emailing the web page URL.
So here is an actual form on amazon.com.
And I've taken out part of the form tag here.
So here's the actual action.
And the method is actually Get.
If we look down at the bottom, you
can see the URL that is generated when somebody clicks
on the Submit button here or actually
the little search icon on the far right of the search
bar there.
And we can see that the action there, /s/ref=nb_sb_noss--
that's our relative reference.
And if you look at the actual URL at the bottom of this image
here, you can see that that gets tacked on
to www.amazon.com, which is what you'd expect
with a relative reference.
So it's saying, hey, when somebody clicks
on the little search icon here to submit the form information,
go ahead and go to this particular location
as specified by the action on the amazon.com server.
But if you look past the nb_sb_noss,
you'll see that there's some additional information here.
And that additional information is actually
determined by the selection of the user on that select tag
and whatever the user has entered into the text field.
And so the first thing we have here is that url=search-alias.
And so it turns out that that electronics
that we're looking at there-- that's
actually part of a select tag.
And the name of the select tag is your url.
And as you may recall from the forms video, when information
is sent from the web browser to the server
and we've got a bunch of elements on our web page,
it's sent in the form of name of element
followed by current value of the element.
So in this particular case, the name of the element is url
and the search-alias equals electronics
is the value of the electronics option
that the user has selected here.
So what's happening here is this information
on the user's current selection is
being sent to the web server.
And it's being sent by attaching it to the URL itself.
And if you're wondering what that %3D is,
that's actually an encoding for that equal sign there.
I mentioned before that you want to be really careful in terms
of what sort of punctuation you put inside of your file names.
And as I've recommended before, I recommend
you stick to lowercase letters, digits 0 through 9, and dashes.
Things like spaces or in this the equal sign
can get transmitted.
But it does get converted using this URL encoding.
So in this particular case, 3D is the hexadecimal encoding
for an ASCII equal sign.
And so you get a %3D sent in place of the actual equal sign
when this goes to the server.
And then the text field there where I've typed in iPad--
the name of that text field is field-keywords.
And then, of course, the value that I've typed in there
is iPad.
And so you can see at the end of the URL it indicates that
I'm submitting information to the server with the value
for field-keywords=iPad.
And so the basic idea here is the URL
here includes the information that I've
entered into the form.
And so there's a number of implications of this.
If I were to bookmark this web page, what's going
to get bookmarked is this URL.
And this URL includes the information
I entered into the form.
So if I go ahead and bookmark this web page
and then I go back to that bookmark in a day or two,
I'm going to get the results of the original search.
It's going to know that I was searching in the electronics
section of Amazon and that I was looking for an iPad.
Similarly, if I were to email this URL to a friend
and they were to click on the link in their email system,
it would include the information from the form that I entered.
So they're going to see the exact same results
as if they had entered this information into this form.
Now let's say we go ahead and change the method on the form
here from Get to Post.
And I do want to emphasize that Amazon uses Get here.
But if you were to go ahead and switch this to Post,
we're going to get some different results here.
What happens with post is the information
is sent to the web server in a different form.
It's not included in the URL.
It's actually stored internally in the HTTP request.
And it's not directly visible just by looking at the URL.
And so the URL with the post request here--
and I do, again, want to emphasize that this
is a change I have made.
This is not actually what occurs on the Amazon website.
The Amazon website uses Get.
But if we were to use this Post request,
notice that the URL here down at the bottom of the page
does not include any indication that I'm
searching in the electronic section
or that I entered the iPad as the keyword
that I'm searching for.
Instead, it just has the action there
tacked on to the end of the server name.
And there's no additional information on the URL.
So the implication here is if I were to go ahead and bookmark
this particular web page, and I were
to go back to that bookmark, it wouldn't
know that I was looking in the electronics section.
And it wouldn't know I was looking for an iPad.
All it would know is that I had submitted a search request
to Amazon.
But it would have no information on what that search was.
And so I would not see the results of that search.
And so if I use a Post request instead
of a Get request in my form and somebody
tries to bookmark the results, they're
not going to be able to bookmark the results.
Similarly, if I go ahead and take this URL here
and I email it to a friend instead of them
seeing the results of my looking for an iPad in the electronics
section, they're just going to see some indication that I
had performed a search on Amazon or they might even
get an error message from Amazon saying,
hey, I see you're trying to do search.
But I don't understand what you're trying to search for.
And that's because with both the bookmarking
and when we take the URL and we email it to people,
the only information being stored by the web browser
for the bookmark is the URL.
And, of course, the only information
that our friend gets is the URL I emailed them.
So when the information is encoded
into the URL with the Get request, that's great.
And people can see exactly what I was looking for
and the information I entered into the form.
But if we're using the Post request,
that information is not included in the URL.
And so we don't get any of the results.
The URL does not include any of the information
about what I entered in the form.
It only knows that I tried to enter some information
but not actually what was associated with it.
So let's go back to our summary here.
So we've seen that Get versus Post
controls how the information is sent to the server.
Either the information is encoded into the URL
or it's enclosed within the actual HTTP request
and it's not included as part of the URL.
And as a consequence, I can bookmark or email URLs
using the Get requests, and people will get
the actual results as I expect.
Whereas if the form is submitted using a Post request,
that information is not included in the URL.
And so it's lost.
There's a second implication of Get versus Post.
And, arguably, this is more important.
But it's something that's not normally seen by users.
But it's very important for getting right
in terms of if you're actually setting up
your server and your web pages.
And that is setting Get versus Post determines whether or not
the state of the server may be changed.
So Get requests are what we refer to as idempotent.
And what idempotent means is they
do not change the state of the server.
And so the idea here is if I make a Get request
and I make another Get request an hour or two later,
that the Get requests should get the exact same result.
So if I go ahead and make a Get request on Amazon looking
for iPads and then I make another request 15 minutes
later, I should get the same results.
That's the implication of using a Get request.
And, in fact, the web browser is welcome to cache the results
in the browser cache, which means
it's going to store the HTTP and any associated files
like CSS files or image files from the original request.
And it's able to look at that.
And there may be some sort of expiration date on that.
But it's able to look at that and say, Oh, you
made this request 15 minutes ago.
I still have the results from the last request.
They haven't expired yet.
So I'm just going to go ahead and display
the previous request.
Post requests in contrast are not idempotent.
This means they can change the state of the server.
So let's take a look at some usage scenarios of forms
and whether or not we would want the result
to be idempotent or not.
So suppose I look up a word in a dictionary or on Wikipedia.
Do I expect the results to change?
Well, hopefully not.
I mean, dictionaries do change.
Language does change.
But it doesn't change very frequently.
So if I make a request to dictionary.com
looking at particular word and then I
make a request 12 hours later, I should
get the exact same results.
There should be no change of the state of the server.
Certainly, my request is not changing
the state of the server.
So this is an important point.
It's not that the state of the server can't be changed.
It's that my submission here is not changing
the state of the server.
So maybe at the end of the year, dictionary.com
decides, hey, this word is being used in different ways.
So they go ahead and change their information
on the server.
But it's not like I am submitting
new information that's changing the state of the server.
Similarly, for Wikipedia, assuming I'm
doing a lookup, that's going to be idempotent.
If I look up information about Stanford University
and I look up that information a little bit later,
the results should be the same.
Now, if I were to be a Wikipedia editor
and I were actually to modify that web page,
well, that's a different request.
And so the way this would work is
that when I'm looking up the information on Wikipedia,
that needs to be a Get requests.
When I'm changing the information on Wikipedia,
that actually needs to be a Post request because it
is make a change on the server.
Let's say I order something from Amazon.
That needs to be a Post request because I'm changing
the state of the server.
The servers database is being modified
to include information about this new order that
has come in.
So if I put in a Get request instead of a Post request,
that will cause problems.
Similarly, if I'm posting something
on an electronic bulletin board, I
expect other people to see it.
That means there needs to be a change on the server in order
for people to see what I posted there.
Same thing if you're posting on Twitter,
or Facebook, or anything like that.
One thing that you may notice with Post request
is if you reload a web page, which has a Post request,
you may get this dialog box saying, hey,
do you want to resubmit this information?
And this is happening because the Post request are
changing the state of the server or at least potentially
changing the state of the server.
And so if I order an iPad at Amazon
and then I reload the web page, what it's saying is, hey,
the first time you clicked on that link you
ordered a new iPad from Amazon.
You're trying to reload the web page.
Should I tell Amazon you want to order a second iPad?
And so this is in contrast with what
happens with a Get request.
With a Get request, I'm just getting information
from the server.
There's no change in the server status.
And so if I reload a web page with a Get request,
the web browser is like that's all good.
I can get you the same results.
And in fact, I may have the results sitting in the cache.
So when you see that do you want to resubmit--
and you may notice that sometimes you get that do you
want to resubmit dialog and sometimes you don't.
And you may be wondering what the difference is.
Well, the difference is that that form is either marked
with method equals Get or method equals Post.
And depending upon which of that settings is being used,
the web browser will either be like it's all good.
I can just redisplay the results.
Or it's saying, hey, this actually
changes the state of the server.
We already did that once.
Do you want me to change the state of the server again?
And so that's what's going on there.
Now it is important that you use the proper method
type for the proper usage.
Using a Get request when you actually
want to use a Post request will cause problems.
If the result of a Get request is still in the web browser
cache as we mentioned before, a second Get request
may not be received by the web server.
And so the idea here is if you actually
want the state of the server to be changed,
you need to use the Post request.
If somebody ordered something from my online store
and we use a Get request, I can ignore the fact
that the Get request is supposed to be idempotent.
And I can go ahead and grab that information on the server.
And I can update my order database.
But if they were to do a second Get request
to order a second version of that item,
the web browser would be completely acting appropriately
if I were to say, hey, you already made this Get request
yesterday.
I still have the results in the web browser cache.
As far as I can tell, it's still valid.
I'm just going to redisplay that.
I'm not even going to bother contacting the server
to tell the server that you're resubmitting
this Get request because the meaning of the Get request
is I'm only returning information.
I'm not actually changing anything on the server.
So if you want to or need to have
the information on the server change,
make sure you use a Post method on your form
and not the Get method on your form.
So Conclusions.
Use a Get request when you can.
It's much more convenient for the user
to have that information there in the URL
and to be able to bookmark it, and email it to people,
and things like that.
Use a Post request when you must.
So if the submission of the form needs to change something
on the state of the server, you definitely
do not want that to happen with a Get request
because as we saw, that can cause problems.
All right, so that's it for forms.
I'll talk to you all soon.