Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll

HTTP Basics

Preview

Start a free Courses trial
to watch this video

Sign up for Treehouse

Sending Data with a POST Request

5:57 with Chris Ramacciotti

There are many times in which HTTP is used to send a request whose purpose is to modify data on the server. POST requests are used for this purpose and are constructed a bit differently than GET requests that send data. In a POST request, data is sent in the request payload instead of in the URI. This video shows you exactly how this is accomplished.

UTF-8 Encoding

The UTF-8 character encoding is one in which every character in the Unicode Character Set can be represented with anywhere from 1 to 4 bytes.

In general, the character encoding of a submitted form is UTF-8 by default. In the video, all the characters that were part of the payload can be represented with 1 byte (8 bits). This is because they're all part of the Basic Latin Characters. See for yourself by looking at the Basic Latin Characters and finding all the ones from our POST request payload in the list:

firstname=Chris&language=English

Since each character in that payload will take up exactly one byte, counting the bytes is equivalent to counting the characters.

What happens if you use a character outside of Basic Latin? For example, consider the scenario that your payload instead looks like this:

greeksigma=Σ

The Greek capital sigma cannot be represented with one byte (it actually takes two). What your browser will do upon submitting a form with a Σ is substitute a URL-encoded version, which in the case of the Greek capital sigma is %CE%A3. So, the HTTP POST payload becomes the following:

greeksigma=%CE%A3

Therefore, when the content-length header is calculated with this URL-encoded version, it has a value of 17, which is what will be included in the HTTP POST request.

Related Discussions

Have questions about this video? Start a discussion with the community and Treehouse staff.

Sign up

    Related Discussions

    Have questions about this video? Start a discussion with the community and Treehouse staff.

    Sign up

    Using the query string in a URI to pass additional data with a GET request 0:00
    is a nice way to fine tune your request and the subsequent response. 0:05
    For example, a server can make sure that a request to the /search resource, 0:09
    is fully accommodated by reading the query string parameter you passed. 0:14
    Which would probably contain your search string, say the string Chicago. 0:18
    In putting together its response the server would include 0:23
    only search results related to Chicago. 0:26
    This is a nice feature of HTTP but its use is limited to the fetching of results, 0:29
    that is these get requests are essentially read only. 0:34
    But what if we want to update a resource to incorporate the data that we pass it? 0:39
    This requires a different kind of request, a POST request. 0:44
    As you recall, in contrast to a GET request, 0:48
    the purpose of a POST request is to make a change on the server. 0:52
    Maybe update a database record, upload a new file to the server or 0:56
    possibly delete data from the server. 1:00
    In short, POST requests lead to a change on the server and 1:03
    in particular, a change to the resource listed in the URI of the request. 1:07
    Recall the scenario mentioned in the previous video 1:13
    where you might be editing a context first name using an html form. 1:15
    A server receiving this request should update the context associated record 1:20
    on the database with the new first name provided. 1:24
    I want to be clear that we won't be looking at how to actually 1:28
    change the resource requested. 1:31
    That's up to the developer of the web application that lives on the server and 1:33
    captures your request. 1:38
    We'll focus here on just the request itself and how it's formatted in http. 1:40
    Let's have a look. 1:46
    In a POST request, additional considerations need to be made. 1:48
    Remember in our HTTP responses we saw content length header? 1:51
    As a reminder, this specified the number of bytes included in the response body. 1:56
    Now it turns out that in a POST request, we'll be transmitting data 2:00
    in the request body or payload and not in the URI like we did in the GET request. 2:04
    Which means we'll need to include a content like header in our request 2:09
    to indicate the number of bytes we are transmitting. 2:13
    For purposes of this demo, I'll simply count the number of characters that I'm 2:17
    using in the data and use that as the number of bytes for the content length. 2:20
    I tell you in the teachers notes why this works for the demo, so here we go. 2:25
    Well, telnet to httpbin.org and 2:29
    issue a POST requesting using HTTP version 1.1. 2:33
    Again, the host is httpbin.org. 2:39
    And the content length header, 2:42
    I'll specify 32 bytes because I'll be passing 32 characters. 2:47
    Make sure to leave a blank line in between the content length header and 2:51
    the request body or payload. 2:54
    Let me just pass a couple pieces of information here. 2:56
    I'll pass my first name and I'll pass a language. 3:00
    Now I'm sending a POST request to the /post resource here because I 3:06
    know that httpbin.org is expecting a POST request at this resource. 3:11
    Usually the name of the resource won't be post. 3:16
    Okay let's make this request, we'll press Enter there. 3:19
    Now, I can see that the server received my request and read my data because 3:23
    that data was used in the response that was sent back right here. 3:27
    first name = Chris and language = English. 3:31
    Cool stuff! 3:35
    Now, lemme show you an example of what might happen if you miscalculate 3:36
    the number of bytes in the request. 3:40
    Let me clear my screen. 3:42
    And I will again telnet to httpbin.org and make a POST request. 3:46
    This time, indicating the Content-Length header as 30 bytes instead of the 32 that 4:01
    I will pass it. 4:06
    I'll pass it the same data that I did last time. 4:06
    Now, when I hit Enter, the response I get is actually not okay. 4:13
    The status listed is 400. 4:18
    Bad request, remember the 400 level codes indicate 4:20
    an error in the client's HTTP request. 4:25
    In this case, it happened because I sent more data, 32 bytes of data, 4:30
    than what I indicated in the Content-Length header, which was 30 bytes. 4:36
    Now you've seen two ways to send data to the resource listed 4:42
    in the URI you've requested. 4:46
    With a GET request, you'll send the data in query string format by 4:48
    appending it to the URI, starting with a question mark. 4:52
    These GET requests are meant to be read only in that they make 4:56
    no changes to the server and only return existing data. 5:00
    We also saw how to send data with a POST request. 5:04
    For this, we drop the data into the request body in query string format, 5:08
    after the blank line that follows the headers. 5:12
    Speaking of which, we need to add a content length header that indicates 5:15
    exactly how many bytes are included in our POST data. 5:19
    And remember, POST requests are intended to modify the resource requested. 5:23
    All that said, I'm exhausted. 5:29
    When it comes down to it, navigating the web and sending data using our manual 5:32
    method is time consuming, error prone and just plain boring. 5:36
    Wouldn't it be nice if there were a GUI for HTTP? 5:41
    During the remaining part of this course, 5:45
    we'll look at how a web browser gives the everyday web surfer the ability 5:47
    to communicate with HTTP without ever having to look at the protocol itself. 5:51

    You need to sign up for Treehouse in order to download course files.

    Sign up

      You need to sign up for Treehouse in order to set up Workspace

      Sign up