- Python - Network Programming
- Python - Network Introduction
- Python - Network Environment
- Python - Internet Protocol
- Python - IP Address
- Python - DNS Lookup
- Python - Routing
- Python - HTTP Requests
- Python - HTTP Response
- Python - HTTP Headers
- Python - Custom HTTP Requests
- Python - Request Status Codes
- Python - HTTP Authentication
- Python - HTTP Data Download
- Python - Connection Re-use
- Python - Network Interface
- Python - Sockets Programming
- Python - HTTP Client
- Python - HTTP Server
- Python - Building URLs
- Python - WebForm Submission
- Python - Databases and SQL
- Python - Telnet
- Python - Email Messages
- Python - SMTP
- Python - POP3
- Python - IMAP
- Python - SSH
- Python - FTP
- Python - SFTP
- Python - Web Servers
- Python - Uploading Data
- Python - Proxy Server
- Python - Directory Listing
- Python - Remote Procedure Call
- Python - RPC JSON Server
- Python - Google Maps
- Python - RSS Feed
Python - HTTP Headers
The request and response between client and server involves header and body in the message. Headers contain protocol specific information that appear at the beginning of the raw message that is sent over TCP connection. The body of the message is separated from headers using a blank line.
Example of Headers
The headers in the http response can be categorized into following types. Below is a description of the header and an example.
Cache-Control
The Cache-Control general-header field is used to specify directives that MUST be obeyed by all the caching system. The syntax is as follows:
Cache-Control : cache-request-directive|cache-response-directive
An HTTP client or server can use the Cache-control general header to specify parameters for the cache or to request certain kinds of documents from the cache. The caching directives are specified in a comma-separated list. For example:
Cache-control: no-cache
Connection
The Connection general-header field allows the sender to specify options that are desired for that particular connection and must not be communicated by proxies over further connections. Following is the simple syntax for using connection header:
Connection : "Connection"
HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion of the response. For example:
Connection: close
By default, HTTP 1.1 uses persistent connections, where the connection does not automatically close after a transaction. HTTP 1.0, on the other hand, does not have persistent connections by default. If a 1.0 client wishes to use persistent connections, it uses the keep-alive parameter as follows:
Connection: keep-alive
Date
All HTTP date/time stamps MUST be represented in Greenwich Mean Time (GMT), without exception. HTTP applications are allowed to use any of the following three representations of date/time stamps:
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
Transfer-Encoding
The Transfer-Encoding general-header field indicates what type of transformation has been applied to the message body in order to safely transfer it between the sender and the recipient. This is not the same as content-encoding because transfer-encodings are a property of the message, not of the entity-body. The syntax of Transfer-Encoding header field is as follows:
Transfer-Encoding: chunked
All transfer-coding values are case-insensitive.
Upgrade
The Upgrade general-header allows the client to specify what additional communication protocols it supports and would like to use if the server finds it appropriate to switch protocols. For example:
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible protocol.
Via
The Via general-header must be used by gateways and proxies to indicate the intermediate protocols and recipients. For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses HTTP/1.1 to forward the request to a public proxy at nowhere.com, which completes the request by forwarding it to the origin server at www.ics.uci.edu. The request received by www.ics.uci.edu would then have the following Via header field:
Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible protocol.
Warning
The Warning general-header is used to carry additional information about the status or transformation of a message which might not be reflected in the message. A response may carry more than one Warning header.
Warning : warn-code SP warn-agent SP warn-text SP warn-date
Example
In the below example we use the urllib2 module to get a response using urlopen. Next we apply the info() method to get the header information for that response.
import urllib2
response = urllib2.urlopen('http://www.tutorialspoint.com/python')
html = response.info()
print html
When we run the above program, we get the following output −
Access-Control-Allow-Headers: X-Requested-With Access-Control-Allow-Origin: * Cache-Control: max-age=2592000 Content-Type: text/html; charset=UTF-8 Date: Mon, 02 Jul 2018 11:06:07 GMT Expires: Wed, 01 Aug 2018 11:06:07 GMT Last-Modified: Sun, 01 Jul 2018 21:05:38 GMT Server: ECS (tir/CDD1) Vary: Accept-Encoding X-Cache: HIT Content-Length: 22063 Connection: close