Skip to content

Sending User Data: Request Parameters

Request parameters allow us to send information to the server that can be used to change how the server will respond to the request. I like to think of request parameters as variables in an Object-Oriented (OO) language.

Note

Without a way of sending these parameters to the server the web would be a very different place.

Dynamic content would be impossible, with the content instead being static (like the pages in a book), so you could only find information if you had the specific link. Quite how we would find these pages would be interesting, as we wouldn't be able to ask Google (or Google would be like the old yellow pages).

Example: A Web Form

Consider the following HTML log-in form:

<form>
  <div class="form-group">
    <label for="username">Username</label>
    <input type="text" name="username">
  </div>
   <div class="form-group">
     <label for="password">Password</label>
     <input type="text" name="password">
  </div>
</form>

When we submit the form, the values in the username and password boxes are sent to the server as parameters. The server can then act on the data that has been sent, and respond appropriately.

Now lets look at a simple python function to examine what could happen on the server1:

def login(username, password):
    if username == "dang" and password == "swordfish":
        return "Login Successful"
    else:
        return "Login Fails"

So our login function takes two parameters and, depending on what is supplied, either returns a success or fail message.

To bring this back to HTTP, this means we need to find a way of sending the parameters to the server by encoding them into the request. Depending on the request type the method of encoding this data changes.

Passing parameters to server using requests

GET requests

GET requests are encoded as part of the URL (do a Google search and look at the URL for a good example of this). The part appended to the string containing the parameters is known as the query string.

The query string is formed of a question mark (?), followed by parameter, value pairs. Multiple parameters are delimited by an ampersand (&).

So submitting the form above with a GET request the query string would be:

http://127.0.0.1/login.html?username=dang&password=swordfish

Note

The data we pass needs to be a valid URL, this means that "special" characters, such as quotes " or amphersands & would not be accepted.

In this case the data is URL Encoded to allow it to be sent.

The benefits of using GET requests and the query string are:

  • They are good for transferring small amounts of data
  • They are easy to debug (we can see the parameters in the URL)
  • They can be bookmarked

However we also need to consider how GET requests work:

  • Requests can be cached
  • Requests can appear in the browser history
    • Or a link between the favicon and request may be cached (leading to possible information disclosure even in 'safe' browsing mode)
  • There is a limit on the length of a request
  • Sensitive data will be transmitted as part of the URL

POST Requests

POST requests are encoded inside the request body. This means that the request itself is only visible by inspecting the headers, rather than as part of the URL. This makes it slightly harder to modify the request, as we cannot just manipulate the URL, and would need to use a tool to add the parameters to the request body. We will discuss manually sending requests to the server in the next step.

The following code block shows a POST request made to httpbin, you can see that the core elements of the request header are the same as the GET request above. However, there is a new field, Body that contains the encoded request parameters.

Host: httpbin.org
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Body: username=dang&password=foobar

POST requests:

  • Can be harder to debug as we need to examine the request headers
  • Only the page remains in the browser history
  • Are not cached
  • Have no restrictions on data length

Important

While the parameters are 'hidden' in the header, do not rely on POST requests to be secure. It is trivial to view the headers, either using the browser developer modes, packet sniffing or third-party tools such as Burp Suite.

Other Ways of Requesting data: REST

REST (Representational state transfer) is another way that a site can allow its users to request data. Rather than a protocol, its a way of designing web pages that means the URL has meaning for data.

Note

We won't go into REST API design in too much detail (because there still isn't really a consensus around it), but understanding how the URL can change the data that is returned is useful.

The main aim of any website is to allow a user to access a specific resource. This resource could be anything, from a specific page on the site, to details of an item stored in a database.

With REST, the URL has meaning, and the way it is constructed can be used to request data from the server. This means that requests for information can be made without needing the usual request parameters.

For example, lets consider a site that where we can browse a list of products. Each product is stored in a database, and has a corresponding ID.

We could fetch the page for a specific item using a request parameter. For example with a GET request /product?productId=<id>.

Under a REST style interface we could view a specific product by appending an ID as a part of the URL itself./products/<id>

When it comes to adding new items, or sending more complex data to the server, REST still uses request parameters in the same way a non-rest site would.

Note

The logical structure REST style routing gives means it is pretty common, especially when dealing with API's that let you query a site programatically.

However, aside from the way we represent the items we are listing (URL parameter or URL Element), there is not a huge practical difference in the two approaches. Using Parameters is the approach taken by Google and Amazon, so it "works at scale".

Summary

In this article we looked at two of the main request types, and how they let us send data to the server.

  • GET Requests encapsulate the data to be sent as part of the URL, using the query string
  • POST Requests place the data inside the request body itself.

We also had a brief introduction to REST, where parts of the query can be represented as a PATH in the URL.

In the next article we will examine how we can make requests from the server, using command line tools, and through a program.

Video

  1. Obviously hardcoded passwords are bad, Don't try this at home kids. ↩

Back to top