UNDERSTANDING HTTP REQUESTS AND RESPONSES

1.

the preferred communication approach in iOSis HTTP. The most convenient networking APIs provided in iOS are geared toward HTTP, the HTTP APIs are the most thoroughly documented, and the high level HTTP APIs are well integrated into the run loop-based architecture of an iOS application. It is no wonder that HTTP and HTTPS are the workhorse protocols of iOS network communications.

2.

INTRODUCING HTTP

There were three major innovations in Berners-Lee’s original proposal: HTML, HTTP, and the URL. 

HTML defined a way to add styling to text, 

HTTP defined a way to convey data between server and client, 

and theURL defined a way to uniquely locate a resource across a network of machines.

3.

UNDERSTANDING HTTP REQUESTS AND RESPONSES

the sequence of steps in a simple HTTP request.：

The client establishes a TCP connection to the server and then sends an HTTP request. The server subsequently responds to the request by sending a HTTP response over the same TCP connection. The client can then reuse the TCP connection for another request or close it. 

The most significant difference between HTTP and HTTPS is during the connection establishment phase of the conversation. After the TCP connection is made but before HTTP requests are transmitted, an SSL session must be established between the client and the server. SSL session establishment includes various stages: the client and server negotiating over which ciphers to use, exchanging public keys, validating the negotiation, and optionally validating identity. After the SSL session is established, all the data transmitted over the TCP connection will be encrypted.

3.

A URL is typically composed of five components, as shown in Figure 3-2.

• Protocol — The protocol component specifies which application layer protocol to use to communicate to the server. If you’ve been around the web for a while, you may remember using ftp as a protocol in addition to http. The dominance of http has led to the near extinction of pre-HTTP protocol usage. Another commonly used protocol in iOS apps is the file protocol. file requests are used to retrieve resources in the local filesystem within the apps sandbox. If you create an NSURL object using a string without a protocol, it defaults to the file protocol.

• Hostname — The hostname portion of the URL specifies the TCP hostname or IP address of the host containing the wanted resource. If the protocol of the URL is FILE, then this component and the port component must be omitted. The exception to the preceding rule about a single URL referencing a unique resource is broken when relative or local hostnames are used. For example, if you uselocalhost as the hostname, the URL refers to the local machine; therefore, the same URL can refer to different resources on different machines.
• Port — The port portion of the URL specifies the TCP port to which the client should connect. If omitted the client uses the default port for the specified protocol: 80 for HTTP and 443 for HTTPS. It is best practice to use these port values for apps running on devices outside networks you control because some network proxies and firewalls will block nonstandard port numbers for security or privacy reasons.
• Absolute-path — The absolute-path component specifies the path to the network resource as if the HTTP server was drilling down into a directory tree. The absolute-path may include any number of path components each separated by the forward slash (/) character. An absolute-path may not contain a question mark, space, carriage-return, or line-feed characters. Many REST services use path components as a means to pass values to uniquely identify an entity stored in a database. For example, a path of/customer/456/address/0 would specify the address at index 0 for the customer with an identifier of 456.
• Query — The last component of a URL is the query string. This value is separated from the absolute-path by a question mark (?). By convention multiple query parameters are each separated by an ampersand (&) character. The query string may not contain carriage return, space, or line-feed characters.

4

An HTTP request consists of three parts: 

the request line, the request headers, and the request body.

GET /search?source=ig&hl=en&rlz=&q=ios&btnG=Google+Search HTTP/1.1 
Host: www.google.com 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0)...
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en,en-us;q=0.7,en-ca;q=0.3 
Accept-Encoding: gzip, deflate 
Connection: keep-alive 
Referer: http://www.google.com/ig?hl=en&source=webhp 
Cookie: PREF=ID=fdf9979...

METHOD	STANDARD USES
GET	Retrieves a piece of content, or entity in HTTP terminology, from the server. GET requests usually don’t contain a request body, but it is allowed. Some network caching appliances will cache only GETresponses. GET requests usually do not cause data changes on the server.
POST	Updates an entity with data provided by the client. A POST request usually has information in the body of the request that is used by the application server. POST requests are considered to be non-idempotent, meaning that if more than one request is processed, the result is different than if only one request is processed.
HEAD	Retrieves metadata about a response without retrieving the entire contents of the response. This method is usually used to check a server for recent content changes without having to retrieve the full content.
PUT	Adds an entity with data provided by the client. A PUT request usually has information in the body of the request that is used by the application server to create the new entity. Usually, PUT requests are considered to be idempotent, meaning that the request can be repeatedly applied with the same results.
DELETE	Removes an entity based on contents of the URI or request body provided by the client. DELETE requests are most frequently used in REST service interfaces.

http://my.safaribooksonline.com/book/-/9781118417164/firstchapter#X2ludGVybmFsX0h0bWxWaWV3P3htbGlkPTk3ODExMTg0MTcxNjQlMkZzZWMxMF9odG1sJnF1ZXJ5PQ==

5.

Response Contents

After the HTTP server and any application servers supporting it finish processing the request, an HTTP response is returned to the client over the same TCP socket. An HTTP response is structured similarly to an HTTP request with the first line being the status line, followed by headers, and a response body. The following code shows a sample HTTP response.

HTTP/1.1 200 OK 
Date: Tue, 27 Mar 2012 12:59:18 GMT 
Expires: -1 
Cache-Control: private, max-age=0 
Content-Type: text/html; charset=UTF-8 
Content-Encoding: gzip 
Transfer-Encoding: chunked 
Server: gws
 
<!doctype html><html itemscope="itemscope"
itemtype="http://schema.org/WebPage">
<head><meta itemprop="image" content="/images/google_favicon_128.png"/>
<title>ios - Google Search</title>
<script>window.google={kEI:"prlxT5qtNqe70AHh873aAQ",
getEI:function(a){var b;
while(a&&!(a.getAttribute&&(b=a.getAttribute("eid"

In iOS’s URL loading system, the NSURLResponse object and its subclass NSHTTPURLResponse encapsulate the data returned from a request. There are two objects in this hierarchy because the URL loading can fulfill requests for data based on non-HTTP URLs. For example, a request for a file:// URL will not contain any headers.