In this course, you'll explore the basic structure of a web application, and how a web browser interacts with a web server. You'll be introduced to the request/response cycle, including GET/POST/Redirect. You'll also gain an introductory understanding of Hypertext Markup Language (HTML), as well as the basic syntax and data structures of the PHP language, variables, logic, iteration, arrays, error handling, and superglobal variables, among other elements. An introduction to Cascading Style Sheets (CSS) will allow you to style markup for webpages. Lastly, you'll gain the skills and knowledge to install and use an integrated PHP/MySQL environment like XAMPP or MAMP.
Request/Response Cycle
Loading...
來自 University of Michigan 的課程
Building Web Applications in PHP
844 個評分
從本節課中
Introduction to Dynamic Web Content
We look at the basic structure of a web application and how a web browser interacts with a web server. We explore the Request-Response Cycle that is the basis of the Hypertext Transfer Protocol (HTTP).
與講師見面
Charles SeveranceProfessor
School of Information
So now what we're going to do is we're going to try to dig even a little bit
deeper in how these HTTP requests work and we're going to make one up by hand.
I'll show you how to talk to one by hand.
So if we look at the RFC, we see that we make a connection to the server.
In this case, we're going to go to data.pr4e.org.
And I'm using the original old protocol from 1990 and increasingly,
servers are refusing to serve documents using the old protocol.
They want at least HTTP 1.1.
But so, not all servers do this, but there's data.pr4e.org.
I got it on a special ancient server so that it always talks HTTP/1.0.
So I can do this demonstration.
HTTP 1.1 is similar.
It's just a little more sophisticated.
But it's harder to type it by hand, okay?
And so that's why I use, I have an old server that does HTTP/1.0.
The HTTP 1.1 still has a GET thing and a URL and
it just has more stuff afterwards that you've gotta put in.
So, but let's go back to the basics, back to the way it was in 1990, 1991.
And that is you talk to your server.
You send a GET request, and hit Enter.
And then away you go, okay?
So here's kind of what I'm going to show you.
I'm going to use a command on my Macintosh called telnet.
Telnet predates the internet.
It's one of the early protocols, FTP file transfer protocol,
SMTP simple mail transfer protocol.
Telnet was the way we logged into servers.
But I'm going to connect to the server.
But instead of connecting to the normal login port,
I'm going to connect to Port 80.
Port 80 is where we expect a web server to be listening.
And so, if there's a web server, then it will connect.
And then it will stop.
And then I will type this command.
Hopefully I will type it fast enough for
the server to not run out of patience with me.
Then I'll hit the Enter, and this is exactly what the server's going to do.
So I'm typing this, and the server's going to respond this.
This is the request.
And this is the response.
And you can do this too.
But realize that fewer and fewer servers talk the classic HTTP/1.0 protocol.
It's so sad, so, but I keep this.
This is my antique server that I can talk the old protocol, okay?
So I'm going to start this up.
By the way, if you're on Windows, it doesn't come with telnet.
But the Bash shell probably might come with telnet, I don't know about that.
But you can Google how to make telnet work on Windows.
And so then you can do this on Windows.
And also you can make telnet host names space port name and it should work.
You should be able to eventually do this on Windows,
you just can't do it out of the box.
Linux of course, this worked perfectly on Linux and Macintosh, right out of the box.
And so now I want to show this to you in telnet.
Now again, you have to do something a little weird on Windows.
But on the Macintosh, it's easy.
So I'm going to type the command, telnet,
this is just the local command, data.pr4e.org.
So that's the server I'm going to talk to, and port 80.
So there's all these web servers, or mail servers, or whatever servers.
And there are ports,
which are like phone extensions that tell you what application to talk to.
And I'm trying to talk to a web server.
And you'll see it's going to use that information to find the IP address,
the actual address of the web server, which is 192.241.136.170.
Now, it is waiting for me to type an HTTP command.
And I gotta type GET, which is the verb, that's give me a document.
And then I have to type the URI or
URL ://data.pr4e.org/page1.htm.
So this is what your browser is sending,
HTTP/1.0 now I have to enter and then I have to enter again.
So now the server responded and so if you look, this is what I typed.
I typed that and I typed this blank line.
I typed that.
And then, the server came back.
This is the entire server response.
And then the server connection closed the connection.
That's telnet telling you that the connection got closed.
So this is a super simple protocol.
I typed two lines and I get all this data back from the server.
And this data can be broken into two parts.
The data can be broken into a header part and a body part.
And so there's a blank line here, and that's exactly what the protocol says.
There's a blank line between the header of the response and the body of the response.
And so the header is all metadata.
But the browser knows things like, how big this file is.
That's how big it's going to be, it knows that it's not supposed to be cached,
it knows that it was last modified on this date, and what kind of a server.
We're talking to an Apache server.
Remember I was talking about Apache in a previous thing.
And it's running on a Linux operating system called Ubuntu.
And one of the more important things in here is this content type,
which tells, basically, the kind of information.
So right now, this is an HTML page.
And so it says, the thing I'm about to give you after this blank line is HTML.
But this could be an image or something else.
And then we wouldn't be able to look at this very well, we look like [SOUND] but
it would be really the image.
And so if you're bringing pictures down or PDFs down, or whatever,
you get the actual picture or the PDF here.
But because this is HTML, we get HTML which has tags in it and it's got its own
little anchor tag and a href and some new clickable text, etc., etc., etc.
And so, this is sort of what the browser is doing on
your behalf when you click on a link, okay?
So that's what happens.
Those of you who had classes from me before,
you know that I am obsessed with the command line.
And you may or may not have heard me told the story,
this is a movie scene that was written by one of my former students.
His name is also Chuck.
And it was initially in the Matrix Reloaded where
Trinity is breaking into the power grid to shut everything down.
And this is actually command line hacking.
The scene was originally written for some kind of a minority report like UI and
he said, that's not how people hack, people hack in the command line.
Just like I just did, and so
part of all cool security hacking movies now is doing something in command line.
And that just reinforces how much I love the command line.
And how much I want you to be able to know how the command line works.
Just because it's super cool and
you can also take a look at the URL and watch that.
Another part of this class ultimately is to get to know our browsers.
And so I just showed you how to hack it but you don't really need to do that,
that's the hardcore way.
Even though sometimes I do that to figure out what's really wrong.
because I have to type the HTTP 1.1 protocol which is harder
than the HTTP/1.0 protocol that I just showed you.
And so our browsers have this developer mode and
then there's thing called firebug in FireFox.
Safari has Preferences.
Sometimes you have to turn these things on.
So I want you to go turn them on.
And I want you to be able to look at this stuff, because this is where you
as a normal web developer are going to diagnose problems with your application.
because like did it screw up in the client, did it screw up in the server,
was there bad data going back and forth?
And so you're going to get used to this, believe me, by the time you're all done.
And concept to developer mode, even if you're not yet writing the application,
it's fun to go figure out when stuff breaks.
What's going wrong in someone else's application.
And so let's take a look at this.
So let me bring up my browser here, take a look at a webpage, www.dr-chuck.com.
And when I type that URL that goes and does the GET request.
But this is a much more complex page because it has pictures and stuff, and
they don't come down as to all with one request.
And so I can do to view develop console, and I can see things.
And so I'm going to go and take a look at my network tab, and
I'm going to do this again.
And so I'm going to type, highlight and
type enter which causes that initial GET request to happen again.
And then you can see all of the network requests that happened.
Okay, and so what happened is to generate this page,
it did 71 request response cycles.
And if I scroll all the way back up to the top here, this was the first one.
The first one was a GET request, okay?
This was a GET request.
It was a GET request to this URL and 200 OK.
I forgot to show you, let me see if I've still got it.
I forgot to show you that the first line of this header response
is an indication if it's good or not.
404 for example, says I didn't find it.
So it did find it.
If I had made a typo mistake here, I could have got a 404.
Let me do this.
I'll make it do a 404.
I'm going to say, GET http://data.pr4e.org
/page4.htm which I know doesn't exist, HTTP/1.0.
So this is a URL that doesn't exist.
This is what happens when your browser sends a request and
it doesn't get a page back.
See, 404 Not Found.
It's the first line of the header.
Again, I typed this stuff, first line of header 404 Not Found, then the blank line.
Now it says something about hey I couldn't find it.
But also sends us 404 Not Found.
Like I said, you don't have to do this by hand.
You do it here and it says, you got a 200.
And then it got all the, remember the headers?
The headers are sitting right here, response headers.
If I go to data.pr4e.org/page1.htm, there we go.
So this is that page and look, we asked for this URL, this is what we asked for.
We got a GET, we got a 200 OK, this was the address, away we go.
And here's the response headers.
We saw those response headers.
They're pretty much the same as these response headers.
And the HTTP 1.1, we used HTTP 1.1 in this one.
And we actually sent a bunch of other stuff.
The stuff here that says what my preferred language is,
what kind of browser I'm using, etc., etc., and so that's some of the data.
This request header stuff, it actually goes right here,
remember when I type that Enter key.
There is a bunch of stuff that goes here.
And then you type the Enter key and it's all these request headers that
are communicating to the server something about what your browser is doing.
You'll get better at this.
So there's the request headers,
then there is the response which is the body part, right?
It's showing you the headers over here and then the body over here.
And then the preview, if it has a preview, but we're not going to worry about that.
So now, let's go back to this one.
So it was, it got some page,
www.dr-chuck.com it was a GET request 200 OK.
This is the IP address of that server.
And we can take a look at the response and it's a bunch of HTML, blah, blah, blah.
Some CSS, blah, blah, blah, blah, blah, blah, blah and that's the first page.
Now the problem was is in this page, we haven't done HTML yet, but in this page,
somewhere, somewhere there is a picture that says, load this image.
And so it reads this as your browser is reading and parsing this,
and I gotta go get a picture.
So it goes and does another request response cycle.
So here's the request for dr-chuck.com, ian_dolphin_small.jpg,
which is that little picture in the upper left hand corner.
And it got a 200 OK, because it all received at once.
And the response, it was an image JPEG,
remember the other one was a text HTML?
And so that's the response headers.
I don't know if I can see a preview.
Yes, you can see a preview.
It would look yucky.
So we don't see the actual text of the actual response.
So there's the second request.
Then it went to this rate my professor picture, then a some other thing,
and on, and on, and on, away it goes.
And it just read that, and it just had to get all kinds of other things,
JavaScript, and widgets.
Now, we will eventually write applications that do lots of these things.
And like I said, eventually, it did 78 requests to get this page constructed.
So there's a lot of things that you can do.
And a lot of, some of the early assignments will be asking you to do
things with this developer console.
Again, so that you can really get to understand the request response cycle.
So we have so much more to learn.
Technologies in the browser, HTML, CSS, the DOM and JavaScript, jQuery.
In the web server, we got our web server, PHP, MySQL, all these things.
We got so many things.
And this is the picture that you're going to get tired of.
Because this is my favorite picture in the whole world.
Because I can tell you in this picture
about the browser that has a Document Object Model.
And I'll draw pictures that look like this, and don't worry.
So this is where HTTP happens.
So there's the network.
And then often the database server and the web server are on different servers and
there's SQL that goes back and forth between them.
Even if they're on the same server, it's kind of like a virtual network connection.
There's the SQL software, there's the Apache web server.
So you will click on a request,
that request will be sent to a server using HTTP.
Then maybe that will have some PHP that comes in.
It goes and runs the PHP.
It makes a connection to the database.
The database reads some data, comes back, sends some stuff back,
does a response, response populates the Document Object Model.
Maybe runs some JavaScript which also messes with the Document Object Model.
And then you see the Document Object Model.
You don't have to know this right now.
I will hit this almost every single lecture.
Because in a web application the notion there's a browser, there's a web server,
there's the database server.
And there are different things going back and forth.
And that web developer console is really looking at this area right here.
And so you have to debug so many things.
And there's a way to debug these things and debug these things.
There's just so much more.
And it's so cool.
It's so cool.
When you really understand how this works, then you can use any web framework,
any browser framework.
And this notion of database back end, web server middle, and browser.
So again, this is not the only way to write applications.
But the concept of the web browser and
even mobile applications have kind of like these three layers sometimes.
Where they have code that runs in the mobile device, server code and
then database code.
And so, there's a lot to understand.
And we'll just start picking this up one thing at a time.
Build a whole bunch of building blocks and then put them all together so
you really understand how web applications work.
