jQuery Mobile 1.3 is now available as a stable release.

This new version spearheads the jQuery team’s efforts to fully incorporate responsive web design principles into its robust library. Among the new features are several widgets optimized for touch interfaces, including smooth panel overlays, dual-handle range sliders, as well as two different options for responsive tables.

The new features

The new panel widgets allow hidden information to be displayed in a very smooth, eye-catching way. With three modes for transitioning—overlay, reveal and push—the panel slides in from the left or right with a swipe, click or press of the keyboard, keeping the design responsive regardless of the user’s chosen method of input.

Also making its debut is a new feature of the tried and true list view: autocomplete! This feature works just as it sounds. Simply begin typing your desired criteria, and voila! Just like a Google search bar, matches are automatically displayed below the input.

Tables in jQuery Mobile 1.3 now allow two additional modes: column toggle and reflow mode. Column toggle mode allows the user to select which columns of a table to hide and which to display. Reflow mode takes responsive web design to heart and solves the headache of formatting tables dynamically for small screens. It does this by breaking down a table and displaying each row as its own table, with the column labels as row headers and the row data transposed into a column format.

What this means for responsive web design

jQuery has long been a dependable framework, favored for its ability to simplify otherwise tedious and complex JavaScript tasks. jQuery Mobile has been tasked since its inception with bringing that same simplicity to the mobile arena, where touch interfaces rule the roost.

Given the nature of having two separate implementations for two different platforms, the jQuery team has witnessed some confusion with the recent responsive web design movement. People have asked whether they should use responsive web design or jQuery Mobile for their sites, to which Todd Parker (member of the jQuery Mobile team) has responded with an emphatic “both”!

Mr. Parker might be on to something here, too. By employing the rich features of the jQuery mobile framework, web designers can quickly blend their mobile sites into a broader responsive strategy without sacrificing innovation.

Only a few of the new features are listed here; the entire change log can be viewed in the release announcement. Also, take a gander at the jQuery Mobile 1.3 demo site for some quality hands-on time.

Do you use jQuery, jQuery Mobile, or both? Which new features are your favorites? Let us know in the comments.

Get Certified Adobe Training for Web Design – 50% off!

Hacking anything connected to the Internet

The Shodan search engine allows anyone to search for anything connected to the Internet and if security settings are not turned on, take control of the device.

Video here: http://money.cnn.com/video/technology/2013/04/05/t-ts-shodan-hacking-devices.cnnmoney/index.html?iid=HP_LN

Students are trying to start a chapter of the Delta Alpha Pi honors society at UMBC.  It is an  honors society for students with documented disabilities. 

Since this is an honors society students must meet specific criteria in order to become a member.  This is a pre-established international honors society so these requirements have been predetermined and unfortunately cannot be manipulated. 

For undergraduate students:

1. Must have a documented disability.

2. Must be interested in disability issues

3. Have a UMBC GPA of at least 3.1

4. Have completed at least 24 credits at any school.

Graduate students are also welcome:

1. Must have a documented disability.

2. Must be interested in disability issues.

3. Have a GPA of at least 3.3

4. Have completed at least 18 credits.

Delta Alpha Pi is a way to celebrate the academic accomplishments of those with documented disabilities. Disabilities include all types as long as they are documented (physical disabilities, learning disabilities, ADHD, Autism Spectrum Disorders, ect.) I want to do this because as a student with ADHD and learning disabilities I have to work harder than the average student to get an A and I know I am not alone.  I realize that a lot of people with disabilities are embarrassed about it or fear it may hurt them for graduate school or going into the work force.  Delta Alpha Pi can only help you because it shows that although you have disabilities you have shown that you can beat the odds. Delta Alpha Pi members also do activities to take away the stigma of disabilities and to educate the community.   

For more information you can contact me at Sjul1@umbc.edu or leave comments below.  The official Delta Alpha Pi honors society website is also attached to this message. 

This is a great opportunity and we just need 10 students to get started! 

Markdown is a simple text-based markup language and conversion tool that allows writers to create great content for the web without having to worry too much about HTML. The syntax of the language is designed to be easy to learn and intuitive. It’s ideal for people that write content for the web but that might be distracted by the HTML syntax.

Note: Markdown wasn’t really designed as a language for creating complete web pages. It’s more suitable for just content areas like the body of a blog post, an article or web page copy.

Markdown files use the .md or .text extensions.

A common problem that faces HTML is that having all those tags in your markup makes it hard to actually read the content without viewing the page in a web browser. Markdown aims to solve this problem by providing a simple, unobtrusive syntax for marking up content elements such as headings, links, lists, images and more!

The Markdown syntax consists of a number of standard characters that represent HTML elements. When you are ready to publish your content, you pass your Markdown code through a converter that generates the HTML code for you.

Converting Markdown to HTML

There are a number of different ways that you can convert your Markdown to HTML.

Use a plugin for your Content Management System.

There are plugins available for many popular Content Management Systems that will allow you to write your content using Markdown. Your Markdown will then be converted to HTML when you save your changes. If you are a WordPress user check out WP-Markdown.

Use a plugin for your Text Editor.

There also plugins available for popular text editors that provide tools for previewing and converting your markdown code. Federico Viticci put together a great list of plugins for Sublime Text 2.

Finally, you can also your the Command Line Tools.

The command line tools that can be downloaded from the project website also allow you to convert your markdown to HTML. If you’re a Mac user with homebrew you can simply do brew install markdown at the terminal to get these tools installed.Once installed, to use the command line interface you issue the following command.

markdown /path/to/input_file.md > output.html

Before I take you through the Markdown syntax lets take a look a simple example.

# Team Treehouse
    Our mission is to bring affordable Technology education to people everywhere, in order to help them achieve their dreams and change the world.

Running this through the Markdown converter would produce the following HTML.

<h1 id="team-treehouse">Team Treehouse</h1>
    <p>Our mission is to bring affordable Technology education to people everywhere, in order to help them achieve their dreams and change the world.</p>

As you can see, the Markdown version is much easier to read. This is one of the biggest benefits of using Markdown and is also one of the reasons that a lot of experienced developers opt to use it over writing pure HTML.

Now that you understand the problem that Markdown is out to solve lets take a detailed look at the syntax.

Headings

There are two different styles for marking up headings, setext and atx. In this article I’m going to focus on the atx style as it supports more heading levels (six levels against the two levels support by the setext style).

To create headings in Markdown you simply prefix the heading text with a pound sign (#) followed by a space. The number of pound signs that you use indicates the importance of the heading.

# Level 1 Heading  
    ## Level 2 Heading  
    ### Level 3 Heading  
    #### Level 4 Heading  
    ##### Level 5 Heading  
    ###### Level 6 Heading

This Markdown would produce the HTML below.

<h1>Level 1 Heading</h1>
    <h2>Level 2 Heading</h2>
    <h3>Level 3 Heading</h3>
    <h4>Level 4 Heading</h4>
    <h5>Level 5 Heading</h5>
    <h6>Level 6 Heading</h6>

In accordance with the HTML specification you can only use up to six pound signs (indicating a level 6 heading). If you use more than six pound signs the converter will not create a heading at all and the pound signs will be visible to the reader.

Paragraphs

Creating paragraphs of text is easy. Simply separate paragraphs using one or more blank lines, you don’t need to use any special characters.

This is a paragraph of text.
    
    This is another paragraph.

This Markdown would create two paragraphs.

<p>This is a paragraph of text.</p>
    <p>This is another paragraph.</p>

Line Breaks

If you want to add a line break simply add two spaces to the end of the line.

This is the first line.  
    This is the second line.

The first line in this example has two spaces at the end so the HTML will include a line break. A single paragraph element encloses both of the lines of text.

<p>This is the first line. <br />
    This is the second line.</p>

Blockquotes

To create a blockquote you need need to prefix each line of the blockqoute with an angled bracket (>) followed by a space. You can create multiple paragraphs within a blockquote using empty lines, as you did before.

> A person who never made a mistake never tried anything new.
    
    > The true sign of intelligence is not knowledge but imagination.

This Markdown would become the following HTML.

<blockquote>
        <p>A person who never made a mistake never tried anything new.</p>
        <p>The true sign of intelligence is not knowledge but imagination.</p>
    </blockquote>

(Quotes provided by the mind of the great Albert Einstein.)

Phrase Emphasis

Adding emphasis to phrases is pretty straightforward. To create a <strong> element, wrap the phrase within double asterisks (**) or double underscores (__). Creating an <em> element requires single asterisks or underscores.

**Double asterisks produces a strong element**    
    __As does double underscores__
    
    *A single asterisk produces an em element*  
    _As does a single underscore_

Here’s the HTML conversion (I added some line breaks).

<p><strong>Double asterisks produces a strong element</strong> <br>
    <strong>As does double underscores</strong></p>
    
    <p><em>A single asterisk produces an em element</em> <br>
    <em>As does a single underscore</em></p>

Lists

Markdown supports both ordered and unordered lists as well as nesting.

Unordered Lists

Unlike in HTML you don’t need to worry about creating an enclosing element for Markdown lists, you only need to focus on the actual list items. To create an unordered list you need to prefix each list item with either an asterisk (*), minus (-) or plus (+) and the follow that up with a space. It is up to you which symbol you use, just be consistent once you have made your choice.

* Item One
    * Item Two
    * Item Three
    
    - Item One
    - Item Two
    - Item Three
    
    + Item One
    + Item Two
    + Item Three

The Markdown above shows three examples of unordered lists using varying syntax. All of these examples will produce the same HTML shown below.

<ul>
    <li>Item One</li>
    <li>Item Two</li>
    <li>Item Three</li>
    </ul>

Ordered Lists

To create an ordered list you prefix each list item with a number, followed by a period, and finally a space. It’s worth noting that the actual number you use doesn’t matter. This is because the number that is displayed to the reader is handled by the browser and not in HTML (although you can manipulate the display behavior using CSS).

1. Item One
    2. Item Two
    3. Item Three
    
    1. Item One
    1. Item Two
    1. Item Three

Both the of the Markdown examples above will be converted into the following HTML.

<ol>
    <li>Item One</li>
    <li>Item Two</li>
    <li>Item Three</li>
    </ol>

Nested Lists

To create nested lists you need to indent the nested list items using 4 spaces (or one tab). You can mix-and-match list types when nesting. So you could have an ordered list nested within an unordered one and vice-versa.

* Item 1
        * Item 1.1
        * Item 1.2
    * Item 2
    * Item 3

The example above demonstrates nesting an unordered list within another unordered list. This would produce the following HTML.

<ul>
        <li>Item 1
            <ul>
            <li>Item 1.1</li>
            <li>Item 1.2</li>
            </ul>
        </li>
        <li>Item 2</li>
        <li>Item 3</li>
    </ul>

Links

The syntax for creating links has been simplified as much as possible. To create a link you first place the link text within square brackets. Immediately following the closing square bracket you then add a pair of regular brackets that contain the link.

[Team Treehouse](http://teamtreehouse.com)

The Markdown above will create a simple link to the Treehouse home page.

<a href="http://teamtreehouse.com">Team Treehouse</a>

You can also add a title attribute to your link by adding the title text after the URL but within the brackets (as shown below). Make sure that you add a space between the URL and the title text.

[Team Treehouse](http://teamtreehouse.com "Learn Web Design, Web Development and More!")

This example would produce the following HTML link, complete with title attribute.

<a href="http://teamtreehouse.com" title="Learn Web Design, Web Development and More!">Team Treehouse</a>

Images

Images use a similar syntax to links. This time the text you place within the square brackets will form the alt text for the image and the URL in the regular brackets will be used as the path to the image file. The whole syntax is prefixed with a bang (!) which indicates that an image should be created not a link.

![The image alt text goes here](http://example.com/icon.png)

The example above will be converted to the following HTML.

<img src="http://example.com/icon.png" alt="The image alt text goes here">

Code

It’s quite common for us programmers to write blog posts that contain code that needs to be displayed in plain text. HTML provides the <pre> and <code> elements to help us accomplish this.

Markdown supports both inline code snippets and code blocks.

Inline Code Snippets

In HTML we would use the <code> element to markup occurrences of variable or file names when they appear inline. When using Markdown we just need to wrap the inline code snippet in backticks (`).

The `index.html` file contains the homepage for your website.

The example above uses backticks to indicate that index.html should be wrapped in a <code> element.

<p>The <code>index.html</code> file contains the homepage for your website.</p>

Code Blocks

For occasions when you have a larger body of code to markup you need a slightly different approach. In HTML we would use <pre> and <code> elements to markup a body of code and preserve the layout of the text.

With Markdown you just need to indent the whole code block by 4 spaces (or one tab). Just like you do with nested lists.

    function solveForX(y) {
            return solve(y);
        }

The code in the example above has been indented by 4 spaces, indicating that it should be wrapped in <pre> and <code> elements.

<pre><code>function solveForX(y) {
        return solve(y);
    }
    </code></pre>

Notice that the indents within the original block of code are unaffected in the HTML output.

Horizontal Rules

To add horizontal rules in your markdown simply use three or more asterisks, minus signs, or underscores in a row. These must be on a single line with no other content for the converter to create a horizontal rule.

***
    ---
    ___

All three of the examples above will produce a <hr> element.

Inline HTML

Markdown is really useful for taking care of simple markup but it falls down when it comes to more complex structures like tables. Luckily you can mix HTML and Markdown together. The Markdown converter will preserve any HTML that it encounters within your Markdown files.

This is a standard paragraph of **text**.
    
    <table>
        <thead>
            <tr>
                <th>First Name</th>
                <th>Last Name</th>
            </tr>
        </thead>
        <tbody>
            <tr>
                <td>Matt</td>
                <td>West</td>
            </tr>
        </tbody>
    </table>
    
    Here is some more text that the _Markdown_ converter will put into a new paragraph.

In the example above the Markdown converter will leave the <table> untouched but will create HTML elements for the remaining content.

<p>This is a standard paragraph of <strong>text</strong>.</p>
    <table>
        <thead>
            <tr>
                <th>First Name</th>
                <th>Last Name</th>
            </tr>
        </thead>
        <tbody>
            <tr>
                <td>Matt</td>
                <td>West</td>
            </tr>
        </tbody>
    </table>
    <p>Here is some more text that the <em>Markdown</em> converter will put into a new paragraph.</p>

It is worth mentioning that the converter does not process Markdown syntax within block-level HTML elements (<div>, <p>, etc.) that have been manually coded. For example the converter would not create a <strong> element around the word ‘Hello’ in this example.

<div>**Hello** Treehouse!</div>

Escaping Markdown Syntax

You may run into instances when the converter is interpreting your use of the syntax characters as a signal to create HTML elements when you don’t really want it too. This can be frustrating at first, but don’t fear there is a solution!

If you want the converter to ignore a character you simply prefix it with a backslash (\).

For example, the asterisks in the example below are escaped with a backslash so the converter would not create an unordered list.

\* Item One  
    \* Item Two  
    \* Item Three

I’ve listed all of the characters used in Markdown syntax below for your reference.

\ ` * _ { } [ ] ( ) # + - . !

Summary

Markdown is a fantastic language for quickly putting together a blog post or some content for a website. Personally I use it a lot. In fact, I used it to write this article.

The main drawback of Markdown is that you are confined to a fairly limited subset of what is available in HTML. Most notably, you cannot define the majority of element attributes in Markdown alone. That said, Markdown wasn’t designed to be a replacement for HTML. It aims to make it simpler for web writers to create content. A goal that I think it achieves very well. The ability to mix-in HTML also allows you to circumvent the issue of being occasionally limited by the native Markdown syntax.

If you haven’t tried using Markdown before I encourage you to check it out. If you regularly write content for the web you could find that it makes your writing experience much more enjoyable.

The post Explaining Markdown appeared first on Treehouse Blog.

HTTP stands for Hypertext Transfer Protocol. It’s a stateless, application-layer protocol for communicating between distributed systems, and is the foundation of the modern web. As a web developer, we all must have a strong understanding of this protocol.

Let’s review this powerful protocol through the lens of a web developer. We’ll tackle the topic in two parts. In this first entry, we’ll cover the basics and outline the various request and response headers. In the follow-up article, we’ll review specific pieces of HTTP – namely caching, connection handling and authentication.

Although I’ll mention some details related to headers, it’s best to instead consult the RFC (RFC 2616) for in-depth coverage. I will be pointing to specific parts of the RFC throughout the article.

HTTP Basics

HTTP allows for communication between a variety of hosts and clients, and supports a mixture of network configurations.

To make this possible, it assumes very little about a particular system, and does not keep state between different message exchanges.

This makes HTTP a stateless protocol. The communication usually takes place over TCP/IP, but any reliable transport can be used. The default port for TCP/IP is 80, but other ports can also be used.

Custom headers can also be created and sent by the client.

Communication between a host and a client occurs, via a request/response pair. The client initiates an HTTP request message, which is serviced through a HTTP response message in return. We will look at this fundamental message-pair in the next section.

The current version of the protocol is HTTP/1.1, which adds a few extra features to the previous 1.0 version. The most important of these, in my opinion, includes persistent connections, chunked transfer-coding and fine-grained caching headers. We’ll briefly touch upon these features in this article; in-depth coverage will be provided in part two.

URLs

At the heart of web communications is the request message, which are sent via Uniform Resource Locators (URLs). I’m sure you are already familiar with URLs, but for completeness sake, I’ll include it here. URLs have a simple structure that consists of the following components:

The protocol is typically http, but it can also be https for secure communications. The default port is 80, but one can be set explicitly, as illustrated in the above image. The resource path is the local path to the resource on the server.

Verbs

There are also web debugging proxies, like Fiddler on Windows and Charles Proxy for OSX.

URLs reveal the identity of the particular host with which we want to communicate, but the action that should be performed on the host is specified via HTTP verbs. Of course, there are several actions that a client would like the host to perform. HTTP has formalized on a few that capture the essentials that are universally applicable for all kinds of applications.

These request verbs are:

• GET: fetch an existing resource. The URL contains all the necessary information the server needs to locate and return the resource.
• POST: create a new resource. POST requests usually carry a payload that specifies the data for the new resource.
• PUT: update an existing resource. The payload may contain the updated data for the resource.
• DELETE: delete an existing resource.

The above four verbs are the most popular, and most tools and frameworks explicitly expose these request verbs. PUT and DELETE are sometimes considered specialized versions of the POST verb, and they may be packaged as POST requests with the payload containing the exact action: create, update or delete.

There are some lesser used verbs that HTTP also supports:

• HEAD: this is similar to GET, but without the message body. It’s used to retrieve the server headers for a particular resource, generally to check if the resource has changed, via timestamps.
• TRACE: used to retrieve the hops that a request takes to round trip from the server. Each intermediate proxy or gateway would inject its IP or DNS name into the Via header field. This can be used for diagnostic purposes.
• OPTIONS: used to retrieve the server capabilities. On the client-side, it can be used to modify the request based on what the server can support.

Status Codes

With URLs and verbs, the client can initiate requests to the server. In return, the server responds with status codes and message payloads. The status code is important and tells the client how to interpret the server response. The HTTP spec defines certain number ranges for specific types of responses:

1xx: Informational Messages

All HTTP/1.1 clients are required to accept the Transfer-Encoding header.

This class of codes was introduced in HTTP/1.1 and is purely provisional. The server can send a Expect: 100-continue message, telling the client to continue sending the remainder of the request, or ignore if it has already sent it. HTTP/1.0 clients are supposed to ignore this header.

2xx: Successful

This tells the client that the request was successfully processed. The most common code is 200 OK. For a GET request, the server sends the resource in the message body. There are other less frequently used codes:

• 202 Accepted: the request was accepted but may not include the resource in the response. This is useful for async processing on the server side. The server may choose to send information for monitoring.
• 204 No Content: there is no message body in the response.
• 205 Reset Content: indicates to the client to reset its document view.
• 206 Partial Content: indicates that the response only contains partial content. Additional headers indicate the exact range and content expiration information.

3xx: Redirection

404 indicates that the resource is invalid and does not exist on the server.

This requires the client to take additional action. The most common use-case is to jump to a different URL in order to fetch the resource.

• 301 Moved Permanently: the resource is now located at a new URL.
• 303 See Other: the resource is temporarily located at a new URL. The Location response header contains the temporary URL.
• 304 Not Modified: the server has determined that the resource has not changed and the client should use its cached copy. This relies on the fact that the client is sending ETag (Enttity Tag) information that is a hash of the content. The server compares this with its own computed ETag to check for modifications.

4xx: Client Error

These codes are used when the server thinks that the client is at fault, either by requesting an invalid resource or making a bad request. The most popular code in this class is 404 Not Found, which I think everyone will identify with. 404 indicates that the resource is invalid and does not exist on the server. The other codes in this class include:

• 400 Bad Request: the request was malformed.
• 401 Unauthorized: request requires authentication. The client can repeat the request with the Authorization header. If the client already included the Authorization header, then the credentials were wrong.
• 403 Forbidden: server has denied access to the resource.
• 405 Method Not Allowed: invalid HTTP verb used in the request line, or the server does not support that verb.
• 409 Conflict: the server could not complete the request because the client is trying to modify a resource that is newer than the client’s timestamp. Conflicts arise mostly for PUT requests during collaborative edits on a resource.

5xx: Server Error

This class of codes are used to indicate a server failure while processing the request. The most commonly used error code is 500 Internal Server Error. The others in this class are:

• 501 Not Implemented: the server does not yet support the requested functionality.
• 503 Service Unavailable: this could happen if an internal system on the server has failed or the server is overloaded. Typically, the server won’t even respond and the request will timeout.

Request and Response Message Formats

So far, we’ve seen that URLs, verbs and status codes make up the fundamental pieces of an HTTP request/response pair.

Let’s now look at the content of these messages. The HTTP specification states that a request or response message has the following generic structure:

message = <start-line>
              *(<message-header>)
              CRLF
              [<message-body>]
    
    <start-line> = Request-Line | Status-Line 
    <message-header> = Field-Name ':' Field-Value

It’s mandatory to place a new line between the message headers and body. The message can contain one or more headers, of which are broadly classified into:

• general headers: that are applicable for both request and response messages.
• request specific headers.
• response specific headers.
• entity headers.

The message body may contain the complete entity data, or it may be piecemeal if the chunked encoding (Transfer-Encoding: chunked) is used. All HTTP/1.1 clients are required to accept the Transfer-Encoding header.

General Headers

There are a few headers (general headers) that are shared by both request and response messages:

general-header = Cache-Control            
                   | Connection        
                   | Date              
                   | Pragma            
                   | Trailer           
                   | Transfer-Encoding 
                   | Upgrade           
                   | Via               
                   | Warning
    

We have already seen some of these headers, specifically Via and Transfer-Encoding. We will cover Cache-Control and Connection in part two.

The status code is important and tells the client how to interpret the server response.

• Via header is used in a TRACE message and updated by all intermittent proxies and gateways
• Pragma is considered a custom header and may be used to include implementation-specific headers. The most commonly used pragma-directive is Pragma: no-cache, which really is Cache-Control: no-cache under HTTP/1.1. This will be covered in Part 2 of the article.
• The Date header field is used to timestamp the request/response message
• Upgrade is used to switch protocols and allow a smooth transition to a newer protocol.
• Transfer-Encoding is generally used to break the response into smaller parts with the Transfer-Encoding: chunked value. This is a new header in HTTP/1.1 and allows for streaming of response to the client instead of one big payload.

Entity headers

Request and Response messages may also include entity headers to provide meta-information about the the content (aka Message Body or Entity). These headers include:

entity-header  = Allow                    
                   | Content-Encoding  
                   | Content-Language  
                   | Content-Length    
                   | Content-Location  
                   | Content-MD5       
                   | Content-Range     
                   | Content-Type      
                   | Expires           
                   | Last-Modified  
    

All of the Content- prefixed headers provide information about the structure, encoding and size of the message body. Some of these headers need to be present if the entity is part of the message.

The Expires header indicates a timestamp of whent he entity expires. Interestingly, a “never expires” entity is sent with a timestamp of one year into the future. The Last-Modified header indicates the last modification timestamp for the entity.

Custom headers can also be created and sent by the client; they will be treated as entity headers by the HTTP protocol.

This is really an extension mechanism, and some client-server implementations may choose to communicate specifically over these extension headers. Although HTTP supports custom headers, what it really looks for are the request and response headers, which we cover next.

Request Format

The request message has the same generic structure as above, except for the request line which looks like:

Request-Line = Method SP URI SP HTTP-Version CRLF
    Method = "OPTIONS"
           | "HEAD"  
           | "GET"  
           | "POST"  
           | "PUT"  
           | "DELETE"  
           | "TRACE"

SP is the space separator between the tokens. HTTP-Version is specified as “HTTP/1.1″ and then followed by a new line. Thus, a typical request message might look like:

GET /articles/http-basics HTTP/1.1
    Host: www.articles.com
    Connection: keep-alive
    Cache-Control: no-cache
    Pragma: no-cache
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Note the request line followed by many request headers. The Host header is mandatory for HTTP/1.1 clients. GET requests do not have a message body, but POST requests can contain the post data in the body.

The request headers act as modifiers of the request message. The complete list of known request headers is not too long, and is provided below. Unknown headers are treated as entity-header fields.

request-header = Accept                   
                   | Accept-Charset    
                   | Accept-Encoding   
                   | Accept-Language   
                   | Authorization     
                   | Expect            
                   | From              
                   | Host              
                   | If-Match          
                   | If-Modified-Since 
                   | If-None-Match     
                   | If-Range          
                   | If-Unmodified-Since
                   | Max-Forwards       
                   | Proxy-Authorization
                   | Range              
                   | Referer            
                   | TE                 
                   | User-Agent

The Accept prefixed headers indicate the acceptable media-types, languages and character sets on the client. From, Host, Referer and User-Agent identify details about the client that initiated the request. The If- prefixed headers are used to make a request more conditional, and the server returns the resource only if the condition matches. Otherwise, it returns a 304 Not Modified. The condition can be based on a timestamp or an ETag (a hash of the entity).

Response Format

The response format is similar to the request message, except for the status line and headers. The status line has the following structure:

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

• HTTP-Version is sent as HTTP/1.1
• The Status-Code is one of the many statuses discussed earlier.
• The Reason-Phrase is a human-readable version of the status code.

A typical status line for a successful response might look like so:

HTTP/1.1 200 OK

The response headers are also fairly limited, and the full set is given below:

 response-header = Accept-Ranges
                     | Age
                     | ETag              
                     | Location          
                     | Proxy-Authenticate
                     | Retry-After       
                     | Server            
                     | Vary              
                     | WWW-Authenticate

• Age is the time in seconds since the message was generated on the server.
• ETag is the MD5 hash of the entity and used to check for modifications.
• Location is used when sending a redirection and contains the new URL.
• Server identifies the server generating the message.

It’s been a lot of theory upto this point, so I won’t blame you for drowsy eyes. In the next sections, we will get more practical and take a survey of the tools, frameworks and libraries.

Tools to View HTTP Traffic

There are a number of tools available to monitor HTTP communication. Here, we list some of the more popular tools.

Undoubtedly, the Chrome/Webkit inspector is a favorite amongst web developers:

There are also web debugging proxies, like Fiddler on Windows and Charles Proxy for OSX. My colleague, Rey Bango wrote an excellent article on this topic.

For the command line, we have utilities like curl, tcpdump and tshark for monitoring HTTP traffic.

Using HTTP in Web Frameworks and Libraries

Now that we have looked at the request/response messages, it’s time that we learn how libraries and frameworks expose it in the form of an API. We’ll use ExpressJS for Node, Ruby on Rails, and jQuery Ajax as our examples.

ExpressJS

If you are building web servers in NodeJS, chances are high that you’ve considered ExpressJS. ExpressJS was originally inspired by a Ruby Web framework, called Sinatra. As expected, the API is also equally influenced.

Because we are dealing with a server-side framework, there are two primary tasks when dealing with HTTP messages:

• Read URL fragments and request headers.
• Write response headers and body

Understanding HTTP is crucial for having a clean, simple and RESTful interface between two endpoints.

ExpressJS provides a simple API for doing just that. We won’t cover the details of the API. Instead, we will provide links to the detailed documentation on ExpressJS guides. The methods in the API are self-explanatory in most cases. A sampling of the request-related API is below:

• req.body: get the request body.
• req.query: get the query fragment of the URL.
• req.originalUrl
• req.host: reads the Host header field.
• req.accepts: reads the acceptable MIME-types on the client side.
• req.get OR req.header: read any header field passed as argument.

On the way out to the client, ExpressJS provides the following response API:

• res.status: set an explicit status code.
• res.set: set a specific response header.
• res.send: send HTML, JSON or an octet-stream.
• res.sendFile: transfer a file to the client.
• res.render: render an express view template.
• res.redirect: redirect to a different route. Express automatically adds the default redirection code of 302.

Ruby on Rails

The request and response messages are mostly the same, except for the first line and message headers.

In Rails, the ActionController and ActionDispatch modules provide the API for handling request and response messages.

ActionController provides a high level API to read the request URL, render output and redirect to a different end-point. An end-point (aka route) is handled as an action method. Most of the necessary context information inside an action-method is provided via the request, response and params objects.

• params: gives access to the URL parameters and POST data.
• request: contains information about the client, headers and URL.
• response: used to set headers and status codes.
• render: render views by expanding templates.
• redirect_to: redirect to a different action-method or URL.

ActionDispatch provides fine-grained access to the request/response messages, via the ActionDispatch::Request and ActionDispatch::Response classes. It exposes a set of query methods to check the type of request (get?(), post?(), head?(), local?()). Request headers can be directly accessed via the request.headers() method.

On the response side, it provides methods to set cookies(), location=() and status=(). If you feel adventurous, you can also set the body=() and bypass the Rails rendering system.

jQuery Ajax

Because jQuery is primarily a client-side library, its Ajax API provides the opposite of a server-side framework. In other words, it allows you to read response messages and modify request messages. jQuery exposes a simple API via jQuery.ajax(settings):

By passing a settings object with the beforeSend callback, we can modify the request headers. The callback receives the jqXHR (jQuery XMLHttpRequest) object that exposes a method, called setRequestHeader() to set headers.

$.ajax({
        url: 'http://www.articles.com/latest',
        type: 'GET',
        beforeSend: function (jqXHR) {
          jqXHR.setRequestHeader('Accepts-Language', 'en-US,en');
        }
      });
    

• The jqXHR object can also be used to read the response headers with the jqXHR.getResponseHeader().
• If you want to take specific actions for various status codes, you can use the statusCode callback:

$.ajax({
      statusCode: {
        404: function() {
          alert("page not found");
        }
      }
    });
    

Summary

So that sums up our quick tour of the HTTP protocol.

We reviewed URL structure, verbs and status codes: the three pillars of HTTP communication.

The request and response messages are mostly the same, except for the first line and message headers. Finally, we reviewed how you can modify the request and response headers in web frameworks and libraries.

Understanding HTTP is crucial for having a clean, simple, and RESTful interface between two endpoints. On a larger scale, it also helps when designing your network infrastructure and providing a great experience to your end users.

In part two, we’ll review connection handling, authentication and caching! See you then.

References

• HTTP specification
• HTTP Definitive Guide