Fix grammar and spelling issues and modify sentence structure for

clarity. ( 06.1.md )

Author: Anchor

en/eBook/06.1.md

@@ -1,44 +1,44 @@
 ## 6.1 Session and cookies
 
-Session and cookies are two common concepts in web browse, also they are very easy to misunderstand, but they are extremely important in authorization and statistic pages. Let's comprehend both of them. 
+Sessions and cookies are two very common web concepts, and are also very easy to misunderstand. However, they are extremely important for the authorization of pages, as well as for gathering page statistics. Let's take a look at these two use cases. 
 
-Suppose you want to crawl a limited access page, like user home page in twitter. Of course you can open your browser and type your user name and password to log in and access those information, but so-called "crawl" means we use program to simulate this process without human intervene. Therefore, we have to find out what is really going on behind our actions when we use browsers to log in.
+Suppose you want to crawl a page that restricts public access, like a twitter user's homepage for instance. Of course you can open your browser and type in your username and password to login and access that information, but so-called "web crawling" means that we use a program to automate this process without any human intervention. Therefore, we have to find out what is really going on behind the scenes when we use a browser to login.
 
-When we get log in page, and type user name and password, and press "log in" button, browser send POST request to remote server. Browser redirects to home page after server returns right respond. The question is how does server know that we have right to open limited access page? Because HTTP is stateless, server has no way to know we passed the verification in last step. The easiest solution is append user name and password in the URL, it works but gives too much pressure to server (verify every request in database), and has terrible user experience. So there is only one way to achieve this goal, which is save identify information either in server or client side, this is why we have cookie and session.
+When we first receive a login page and type in a username and password, after we press the "login" button, the browser sends a POST request to the remote server. The Browser redirects to the user homepage after the server verifies the login information and returns an HTTP response. The question here is, how does the server know that we have access priviledges for the desired webpage? Because HTTP is stateless, the server has no way of knowing whether or not we passed the verification in last step. The easiest and perhaps the most naive solution is to append the username and password to the URL. This works, but puts too much pressure on the server (the server must validate every request against the database), and can be detrimental to the user experience. An alternative way of achieving this goal is to save the user's identity either on the server side or client side using cookies and sessions.
 
-cookie, in short it is history information (including log in information) that is saved in client computer, and browser sends cookies when next time user visits same web site, automatically finishes log in step for user.
+Cookies, in short, store historical information (including user login information) on the client's computer. The client's browser sends these cookies everytime the user visits the same website, automatically completing the login step for the user.
 
 ![](images/6.1.cookie2.png?raw=true)
 
 Figure 6.1 cookie principle.
 
-session, in short it is history information that is saved in server, server uses session id to identify different session, and the session id is produced by server, it should keep random and unique, you can use cookie to get client identity, or by URL as arguments.
+Sessions, on the other hand, store historical information on the server side. The server uses a session id to identify different sessions, and the session id that is generated by the server should always be random and unique. You can use cookies or URL arguments to get the client's identity.
 
 ![](images/6.1.session.png?raw=true)
 
 Figure 6.2 session principle.
 
-## Cookie
+## Cookies
 
-Cookie is maintained by browsers and along with requests between web servers and browsers. Web application can access cookies information when users visit site. In browser setting there is one about cookies privacy, and you should see something similar as follows when you open it:
+Cookies are maintained by browsers. They can be modified during communication between webservers and browsers. Web applications can access cookie information when users visit the corresponding websites. Within most browser settings, there is one setting pertaining to cookie privacy. You should be able to see something similar to the following when you open it.
 
 ![](images/6.1.cookie.png?raw=true)
 
 Figure 6.3 cookie in browsers.
 
-Cookie has expired time, and there are two kinds of cookies based on life period: session cookie and persistent cookie.
+Cookies have an expiry time, and there are two types of cookies distinguished by their life cyles: session cookies and persistent cookies.
 
-If you don't set expired time, browser will not save it into local file after you close the browser, it's called session cookies; this kind of cookies are usually saved in memory instead of local file system.
+If your application doesn't set a cookie expiry time, the browser will not save it into the local file system after the browser is closed. These cookies are called session cookies, and this type of cookie is usually saved in memory instead of to the local file system.
 
-If you set expired time (setMaxAge(60*60*24)), browser will save this cookies in local file system, and it will not be deleted until reached expired time. Cookies that is saved in local file system can be shared in different processes of browsers, for example, two IE windows; different kinds of browsers use different process for handling cookie that is saved in memory. 　　
+If your application does set an expiry time (for example, setMaxAge(60*60*24)), the browser *will* save this cookie to the local file system, and it will not be deleted until reaching the allotted expiry time. Cookies that are saved to the local file system can be shared by different browser processes -for example, by two IE windows; different browsers use different processes for dealing with cookies that are saved in memory. 　　
 
 ## Set cookies in Go
 
-Go uses function `SetCookie` in package `net/http` to set cookie:
+Go uses the `SetCookie` function in the `net/http` package to set cookies:
 
 	http.SetCookie(w ResponseWriter, cookie *Cookie)
 
-`w` is the response of the request, cookie is a struct, let's see how it looks like:
+`w` is the response of the request and cookie is a struct. Let's see what it looks like:
 
 	type Cookie struct {
 	    Name       string
@@ -58,54 +58,54 @@ Go uses function `SetCookie` in package `net/http` to set cookie:
 	    Unparsed []string // Raw text of unparsed attribute-value pairs
 	}
 
-Here is an example of setting cookie:
+Here is an example of setting a cookie:
 
 	expiration := *time.LocalTime()
 	expiration.Year += 1
 	cookie := http.Cookie{Name: "username", Value: "astaxie", Expires: expiration}
 	http.SetCookie(w, &cookie)
 
 
-## Get cookie in Go
+## Fetch cookies in Go
 
-The above example shows how to set cookies, let's see how to get cookie:
+The above example shows how to set a cookie. Now let's see how to get a cookie that has been set:
 
 	cookie, _ := r.Cookie("username")
 	fmt.Fprint(w, cookie)
 
-Here is another way to get cookie:
+Here is another way to get a cookie:
 
 	for _, cookie := range r.Cookies() {
 	    fmt.Fprint(w, cookie.Name)
 	}
 
-As you can see, it's very convenient to get cookie in request.
+As you can see, it's very convenient to get cookies from requests.
 
-## Session
+## Sessions
 
-Session means a series of actions or messages, for example, your actions from pick up your telephone to hang up can be called a session. However, session implied connection-oriented or keep connection when it's related to network protocol.
+A session is a series of actions or messages. For example, you can think of the actions you between picking up your telephone to hanging up to be a type of session. When it comes to network protocols, sessions have more to do with connections between browsers and servers.
 
-Session has more meaning when it hits web development, which means a solution that keep connection status between server and client, sometimes it also means the data storage struct of this solution.
+Sessions help to store the connection status between server and client, and this can sometimes be in the form of a data storage struct.
 
-Session is the server side mechanism, server uses something like (or actually) use hash table to save information.
+Sessions are a server side mechanism, and usually employ hash tables (or something similar) to save incoming information.
 
-When an application need to assign a new session for the client, server should check if there is any session for same client with unique session id. If the session id has already existed, server just return the same session to client, create a new session if there is no one for that client (it usually happens when server has deleted corresponding session id but user append ole session manually).
+When an application needs to assign a new session to a client, the server should check if there are any existing sessions for same client with a unique session id. If the session id already exists, the server will just return the same session to the client. On the other hand, if a session id doesn't exist for the client, the server creates a brand new session (this usually happens when the server has deleted the corresponding session id, but the user has appended the old session manually).
 
-The session itself is not complex, but its implementation and deployment are very complicated, so you cannot use "one way to rule them all".
+The session itself is not complex but its implementation and deployment are, so you cannot use "one way to rule them all".
 
 ## Summary
 
-In conclusion, the goal of session and cookie is the same, they are both for overcoming defect of HTTP stateless, but they use different ways. Session uses cookie to save session id in client side, and save other information in server side, and cookie saves all information in client side. So you may notice that cookie has some security problems, for example, user name and password can be cracked and collected by other sites.
+In conclusion, the purpose of sessions and cookies are the same. They are both for overcoming the statelessness of HTTP, but they use different ways. Sessions use cookies to save session ids on the client side, and save all other information on the server side. Cookies save all client information on the client side. You may have noticed that cookies have some security problems. For example, usernames and passwords can potentially be cracked and collected by malicious third party websites.
 
-There are two examples:
+Here are two common exploits:
 
-1. appA setting unexpected cookie for appB.
-2. XSS, appA uses JavaScript `document.cookie` to access cookies of appB.
+1. appA setting an unexpected cookie for appB.
+2. XSS attack: appA uses the JavaScript `document.cookie` to access the cookies of appB.
 
-Through introduction of this section, you should know basic concepts of cookie and session, understand the differences between them, so you will not kill yourself when bugs come out. We will get more detail about session in following sections.
+After finishing this section, you should know some of the basic concepts of cookies and sessions. You should be able to understand the differences between them so that you won't kill yourself when bugs inevitably emerge. We'll discuss sessions in more detail in the following sections.
 
 ## Links
 
 - [Directory](preface.md)
 - Previous section: [Data storage and session](06.0.md)
-- Next section: [How to use session in Go](06.2.md)
+- Next section: [How to use session in Go](06.2.md)