HTML Form Submission Requests

Imagine you’re mailing an order form to a store: you fill out your name, the product you want, maybe your payment information, then seal it in an envelope and send it off. When the store receives your envelope (the request), they process the details (the form inputs) and, ideally, redirect you to a new page or send you a receipt. In the web world, HTML forms work in a similar way: when you click that Submit button, your browser creates a request with your form data and sends it to the server.

In this lesson, you’ll learn what a typical HTML form submission request looks like (under the hood) and how the server typically responds.

HTML Form Review

An HTML form is like a note you pass to the server. It can have various input fields (text, dropdowns, checkboxes, etc.), and each field has a name that ties it to a particular piece of data. Two especially important attributes are:

• method – Typically "POST" when you’re sending data that will create or update resources on the server.
• action – The URL (or path) where the form data will be sent.

Here’s an example form that sends a POST /dog request:

<form method="post" action="/dog">
  <input type="text" name="name" />
  <select name="color">
    <option value="black">Black</option>
    <option value="brown">Brown</option>
    <option value="yellow">Yellow</option>
    <option value="white">White</option>
  </select>
  <input type="number" name="age" />
  <textarea name="description"></textarea>
  <button type="submit">Create Dog</button>
</form>

Submitting this form sends data for a new dog (name, color, age, description) to the server. Your browser packages all these details—like sealing an order form in an envelope— and ships them off to the /dog endpoint.

What the Browser Sends

When you click Submit, your browser creates a request with:

• method – Based on the method attribute, typically POST.
• URL path – Based on the action attribute, e.g. /dog in our example.
• Content-Type header – Usually application/x-www-form-urlencoded for standard forms, meaning it’s encoded as key-value pairs.
• body – The actual form data, e.g. name=Fido&color=brown&age=3....

This is akin to an envelope that has “POST” written on it, marked with the address /dog, labeled application/x-www-form-urlencoded, and stuffed with the form data inside.

How the Server Responds

On the server side, you typically parse the form data (read the envelope’s contents), perform some CRUD action—like adding a new dog to a database—and then send the user elsewhere. Think of it like the store confirming your order, then giving you a new receipt or page.

The typical pattern is:

1. Parse the request body
2. Perform the needed action (create, read, update, or delete)
3. Send back a response that redirects the user to another page

In HTTP, a redirection response uses status code 302 and a Location header. It’s like the store saying, “Thanks for your purchase, now go check out your order summary at /orders/confirmation.”

HTTP/1.1 302 Found
Location: /orders/confirmation

Once the browser sees this 302 redirect with Location: /orders/confirmation, it automatically navigates you to that new page—no further action needed from you.

Form Submission Flow

A typical form submission flow can be broken down into steps:

• Form is submitted – The user clicks “Submit” on your HTML page.
• Browser makes request – Sends the form data to the specified endpoint.
• Server does stuff – Reads the body, processes or stores the data.
• Server sends redirection – Usually a 302 redirect to a new page.
• Browser follows redirect – Loads the page at the new Location.

In practice, this allows for a seamless user experience—after submission, they see a confirmation page or some relevant results instead of staring at a blank screen.

What You’ve Learned

In this tutorial, you explored how HTML form submissions work from the browser’s perspective and how servers commonly respond. Specifically, you discovered:

• How the method and action attributes shape the form’s HTTP request.
• What data the browser includes in the request (method, path, headers, body).
• Why servers often respond to form submissions with a 302 redirect and a Location header.
• The typical flow of events when a user hits “Submit.”

These concepts form the foundation of building interactive websites: capturing user input via forms, sending it to the server, and then guiding the user to the appropriate next step. It’s a tried-and-true pattern you’ll see in every major site—from logging in, to posting tweets, to filling out a checkout form in an online store.