So you want to how web.py works?
In this article,i will walk through the web.py’s simple server,which is adopted from CherryPy.
In my words, a web server is simply a request/reponse manager.
It listens comming requests from the client,and dispatches requests to the appropritate application based on the rules.
Then it gets responses back from the same application,and send back to the client later.
There are a couple of things we need to go deeper.
- What is a request ?
When a user click a link or post a form,a request has been created.How?
Well,the client will try to make a connection to the server based on the TCP/IP protocal.(sorry,i won’t go down HTTP level at this article.)
When the connection has been established,it means that we can talk to the server.What?you can think that we get a bridge to the server.So we can send things to the server or get things from it.
We divide these requests into different groups based on their types,like POST,GET,HEAD and so on.It may be more clear when we talk about it in a different angle.Let’s see what makes a GET request.
Suppose we use wget to make a GET request.
And here is the request data:
- How does a request come to the server?
The request would be packaged in a packet via the internet protocal,being encoded into bits,then transformed into optical signal ,finally sended to the server with the help of optical cable.
When the request packet arrives at the server,the packet would be unpackaged back to the request data.
Have a look at OSI_model.
- what are the rules?
The rules are defined by us.You can simply judge that if the request data contain ‘Host: douban.com’,then the server should dispatch the request to the A application.
what is the response?
when the A application gets the request,it would change it to a dict (in python words).And the application would do some stuff on it based on the request type,Host info and so on.
When all these have been done,it would give a dict back.And we call this dict ‘a response’.
The server gets the response,and gives it back to the client.
How does the server and application communicate with each other?
It may be strange that we ask such a question.Why?
Just imagine that you are the framework maker,and you write a func or a class to get a request or push back a response to the server,like Nginx.
And some other framework maker also write some func(which may be so different from yours) to do the same things.
Things are going to be a mess!!We need a specification to guide people to write such code.And now we have some stuff like cgi,wsgi.
- CherryPyserver in general
In fact, webpy does not implement its own server.It just adopts another framework’s server,the crazy
From the image below, you can see that there are serveral classes which workes together to make a server.
From the above chat we can tell that the CherryPyWSGIServer is inherited from HTTPServer.
And it uses the HTTPConnection class to represent comming requests,
and handles them by the ThreadPool class.
The WSGIGateWay1.0 is used to get the request enviroment information,and correctly responses to the server according to the wsgi specification.
- In a little detail
In fact, when we develop a webpy app,we would write some code like these:
app.run() is excuted,a web server has been setted up,which is our
CherryPyWSGIServer instance in default.
And the wsgi specification has defined rules about the talk convention between the server and the application.In my words,it would be like these:
本文采用知识共享署名-非商业性使用 4.0 国际许可协议进行许可