We often need to be able to send rich media like images and videos through websites. But how do websites actually manage to do this? The answer is Multipurpose Internet Mail Extensions, or MIME. Let's take a closer look at how this works. Modern day web applications use loads of resources to build rich interactive experiences. These often include things like images, videos and animations. Delivering these assets along with the HTML and CSS, requires the capability to attach them to HTTP requests. Since attaching items of different types is commonplace when sending emails, the technology developed to allow this has been adapted for use with HTTP. 

Multipurpose Internet Mail Extensions, or MIME, was designed as a flexible message format for sending multimedia objects through email. The HTTP version does add a few features that are different from the email version though. For instance, there isn't a need to send the message body as a seven bit ASCII data as required by some email systems. The MIME message consists of a header, which is made up of a few colon separated fields. The simplest document could be nothing more than a content-type line, followed by a carriage return line feed, CRLF pair and the message body. The content-type header line identifies the data in the body and it's made up of a type and subtype field. And could be something like content-type, text forward slash HTML. 

It's used by the browser to select the right application to display the returned data. Official content types are defined by the Internet Assigned Numbers Authority, IANA, and the list is growing all the time. 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 differs from email in that each submessage can contain a full set of HTTP header fields, not just the content field. 

For example, if you wanted to upload multiple photos to a website, it will provide the interface to select and upload files. Each file to be uploaded will have its own part of the message to include the file data that is clearly defined. Without multipart messages, you'd only be allowed to upload a single photo at a time. And that's it for this video. Understanding how a server provides a response is important because you'll need to be able to decipher what comes back when you make a request to a service. It may be that the service is internal, and you'll be able to go and speak to the team or developer who created the backend service. But if it's an external service, you'll need to be able to know what the server is expecting and what to expect to receive back from different requests.

Lectures

• Clients and Servers
• URLs
• HTTP and its Interactions
• Client Requests in Details
• Server Response
• Security Issues and HTTPs