Skip to main content

Requests and Responses

Updated Feb 26, 2019 ·

Client Requests​

HTTP client requests consist of a method, URI, HTTP version, and a MIME-like message, which are essential for the functionality of HTTP in handling client requests.

URIs​

URIs, or Uniform Resource Identifiers, are formatted strings used to identify networked resources.

  • Absolute URIs: Contain all necessary information, including scheme, host name, and port number.
  • Relative URIs: Begin with the path, with other elements relative to the hosting page.
  • Best Practice: Use relative URIs when referring to resources within your site to maintain flexibility amid changes in scheme or host name.

HTTP Versions​

HTTP version numbers consist of a major and a minor part, indicating advancements or changes in message format handling. Higher minor numbers indicate iterative advancements without altering how requests are processed.

Note that major number changes reflect changes in message format.

  • Version 1.1: Most widely adopted, supporting common browsers and websites.

  • Version 0.9: The original HTTP version supporting only the GET method without MIME usage.

  • Version 2.0: Widely supported, enhancing efficiency and security in data transfer.

  • Version 3.0: Currently under development, aiming to further optimize data transfer capabilities.

MIME-like Messages​

MIME-like messages in HTTP requests include modifiers and form data.

  • These messages enable the transfer of various types of data, such as audio, video, images, and applications, as part of the request.
  • They are crucial for transmitting attachments and enhancing the versatility of HTTP requests.

Server Response​

After receiving an HTTP request from a client, the server can issue either a simple or a full response. A simple response occurs when the server supports only HTTP 0.9 and provides a file or data.

For servers using HTTP 1.0 and above, a full response includes a status line as its first part. The status line consists of:

  • The HTTP version,

  • A standard status code, and

  • A reason phrase.

Components of a Full Response​

A full HTTP response comprises several key components that provide essential information about the response:

  • HTTP Version: Can be 1.0, 1.1, or 2.0.
  • Status Code: A standard three-digit internet server format.
  • Reason Phrase: A textual representation of the status code.

Diagram:

Common HTTP Status Codes​

  • 404 Not Found: Indicates that the requested resource could not be found.
  • 200 OK: Signifies that the request was successful.
  • 304 Not Modified: Indicates that the resource has not been modified since the last requested.
  • 403 Forbidden: Indicates that the server understood the request but refuses to authorize it.
  • 503 Service Unavailable: Indicates that the server is currently unable to handle the request due to temporary overload or maintenance.

MIME-like Message​

The second part of a full HTTP response is the MIME-like message generated by the server. This message includes various header fields separated from the message body by a carriage return line feed (CRLF) pair.

  • HTTP Header Information

    • Provides contextual information about the response.
    • Content type (e.g., text/plain, application/JSON), expiry date, and server software.
    • Enhances security measures.

  • Message Body and MIME

    • Contains the requested resource.
    • Can be dynamically generated, especially for backend server scripts.
    • Interacts with other programs or resources on the web server.

An example includes creating new information in a database, ensuring the response contains a valid MIME message with appropriate header fields.

MIME and HTTP​

Originally designed for email and adapted for HTTP in web applications, MIME enables the sending of rich media, such as images and videos, through websites.

Resource Delivery in Web Applications:

  • Modern web applications utilize various resources like images, videos, and animations.
  • These assets need to be attached to HTTP requests to deliver a complete interactive experience.

MIME Features in HTTP:

  • Adapted from email MIME format for HTTP use.
  • No requirement for the message body to be seven-bit ASCII data, unlike some email systems.

MIME Message Components:

  • Consists of a header with colon-separated fields.
  • Simplest document includes a content-type line followed by a CRLF pair and the message body.

Content-Type Header Line:

  • Identifies the data in the body.
  • Comprises type and subtype fields, such as content-type: text/html.
  • Used by the browser to select the appropriate application for displaying returned data.

Official Content Types:

  • Defined by the Internet Assigned Numbers Authority (IANA).
  • Growing list of content types to accommodate various data formats.

Some of the most common types are application, or JSON, plain, or text, and image, maybe PNG, for instance.

Experimental content types are normally preceded by letters although as browsers and servers can negotiate acceptable types, this is not enforced. MIME also allows the server to send multipart messages. The message body can contain multiple MIME messages, each with a header specifying the type of body data.

HTTP Usage vs. Email​

In HTTP, each submessage can contain a comprehensive set of HTTP header fields, unlike email, which typically focuses on the content field alone. This allows for more detailed and specific communication between clients and servers.

Example Scenario: File Upload Consider the process of uploading multiple photos to a website. The typical steps include:

  • Selecting multiple files via a web interface.
  • Each file is uploaded as a separate part within the HTTP message.
  • Each part clearly defines the file data, ensuring proper handling and identification.

Importance of Multipart Messages:

  • Multipart messages enable the uploading of multiple files simultaneously.
  • Without this feature, users would be limited to uploading one file at a time.

Security Issues and HTTPS​

As the internet has evolved, security has become a paramount concern. HTTP alone is insufficient for protecting data from interception and unauthorized access. This gap is bridged by HTTPS, which provides a secure layer over HTTP.

HTTPS encrypts data at the source, ensuring that only the intended recipient with the correct encryption key can decrypt it.

  • Web servers need an SSL certificate from a reputable Certification Authority (CA).
  • The server holds a private key (never transmitted) and a public key.
  • The public key is returned to the client upon request.
  • Subsequent communications are encrypted using the public key.

This data can only be decrypted using the private key stored securely on the server. The public key on the client end can only decrypt data that has been encrypted by the private key, ensuring the data's origin and integrity.

Common Security Threats​

Eavesdropping​

Data transmitted over unsecured networks is susceptible to interception. Attackers can capture the data being sent between a client and a server, gaining access to sensitive information such as login credentials, personal details, and financial data.

Modification or Fabrication​

Intercepted messages can be altered or fabricated to deceive recipients. Attackers may modify the data being sent, leading to incorrect information being displayed, or fabricate messages to trick users into taking harmful actions, such as providing additional sensitive information or downloading malware.

Impersonation​

Attackers can impersonate systems or users to gain unauthorized access to resources. By pretending to be a legitimate user or system, attackers can exploit vulnerabilities to access restricted areas, steal data, or perform malicious actions without being detected.

For more information, please see Social Engineering Attacks.