In this article, how HTTP represent GET and POST requests, how they transfer cookies, and indeed how they accomplish all communication between browsers and web servers.
GET Request
When your web browser makes a request for the URL www.example.com/path/resource, the browser performs a DNS lookup for the IP address of www.example.com, opens a TCP connection on port 80 to that IP address, and sends the following data:GET /path/resource HTTP/1.1
Host: www.example.com
[blank line]
There will usually be some extra headers, too, but that’s all that’s strictly required. The web server
responds with something like the following:
HTTP/1.1 200 OK
Date: Wed, 31 Mar 2010 14:39:58 GMT
Server: Microsoft-IIS/6.0
Content-Type: text/plain; charset=utf-8
<HTML>
<BODY>
I say, this is a <i>fine</i> web page.
</BODY>
</HTML>
POST Request
POST requests aren’t much more complicated. The main difference is that they can include a payload that’s sent after the HTTP headers. Here’s an example, this time including a few more of the most common HTTP headers:POST /path/resource HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 Firefox/2.0.0.12
Accept: text/xml,application/xml,*/*;q=0.5
Content-Type: application/x-www-form-urlencoded
Referer: http://www.example.com/somepage.html
Content-Length: 45
Cookie: Cookie1=FirstValue; Cookie2=SecondValue
firstFormField=value1&secondFormField=value2
The payload is a set of name/value pairs that normally represents all the input controls in a form tag. As you can see, cookies are transferred as a semicolon-separated series of name/value pairs in a single HTTP header.
Note that you can’t strictly control cookie expiration. You can set a suggested expiry date, but you can’t force a browser to honor that suggestion (it can keep sending the cookie data for as long as it likes).
0 comments:
Post a Comment