web cache 整理

Cache Processing Steps 

1.  Receiving—Cache reads the arriving request message from the network.
   
2.  Parsing—Cache parses the message, extracting the URL and headers.
   
3.  Lookup—Cache checks if a local copy is available and, if not, fetches a copy (and stores it locally). 
   
4.  Freshness check—Cache checks if cached copy is fresh enough and, if not, asks server for any updates.   
5. Response creation—Cache makes a response message with the new headers and cached body.  
   
6. Sending—Cache sends the response back to the client over the network.
   
7. Logging—Optionally, cache creates a log file entry describing the transaction. 

the steps illustrated in the figure:

Cache Processing Flowchart in the figure:

User Login 

user login Flowchart in the figure:

Here's what's happening in this figure:  

1. In Figure a, a browser makes a request from the www.joes-hardware.com site.  
2. The site doesn't know the identity of the user, so in Figure b, the server requests a login by returning the 401 Login Required HTTP response code and adds the WWW-Authenticate header. This causes the browser to pop up a login dialog box.  
3. Once the user enters a username and a password (to sanity check his identity), the browser repeats the original request. This time it adds an Authorization header, specifying the username and password. The username and password are scrambled, to hide them from casual or accidental network observers.
4. Now, the server is aware of the user's identity. 
5. For future requests, the browser will automatically issue the stored username and password .when asked and will often even send it to the site when not asked. This makes it possible to log in once to a site and have your identity maintained through the session, by having the browser send the Authorization header as a token of your identity on each request to the server. 
   

How Cookies Work 

Slapping a cookie onto a user, the flowchart in the figure:

the below figure shows a transaction sequence captured from an Amazon.com visit: 

1.   Figure a—Browser requests Amazon.com root page for the first time.  
2.  Figure b—Server redirects the client to a URL for the e-commerce software.  
3. Figure c—Client makes a request to the redirected URL.  
4. Figure d—Server slaps two session cookies on the response and redirects the user to another URL, so the client will request again with these cookies attached. This new URL is a fat URL, meaning that some state is embedded into the URL. If the client has cookies disabled, some basic identification can still be done as long as the user follows the Amazon.com-generated fat URL links and doesn't leave the site.  
5. Figure e—Client requests the new URL, but now passes the two attached cookies.  
6. Figure f—Server redirects to the home.html page and attaches two more cookies.  
7. Figure g—Client fetches the home.html page and passes all four cookies.  
8. Figure h—Server serves back the content.  

Authentication 

the below figure shows a Simplified challenge/response authentication 

the below figure shows a Basic authentication example

the below figure shows a Generating a basic Authorization header from username and password

the below figure shows a  Web server versus proxy authentication