YanoSec
Progress0 of 152 lessons complete

Course / 06 Web basics / Lesson 05 of 08

HTML forms and what the browser sends

Estimated time: 15 min reading · 15 min activity

A form can show one label while submitting a different field name. To follow what a server receives, read the control’s name and current value rather than copying the words next to it. You will predict two small submissions from source without sending them.

An HTML form groups controls, elements used to enter or choose values. The input element here is a text control. A label is visible text explaining that control. The name attribute supplies its submitted key, and the current control value supplies the paired data. In these unchanged examples, value in the markup supplies that initial value.

The surrounding form has an action, its destination path, and a method describing the request. The supplied forms use POST. The earlier HTTP lesson introduced methods and message bodies; here you will trace which data enters that body.

Before you begin

Estimated time
15 min reading, 15 min activity. Setup and optional practice may take longer.
Where you work
Use the complete printed cards with paper or a text editor for notes. No account, external target, or installation is required. A local HTML file can be read as source; that reading does not perform an HTTP exchange. The curl lesson gives a separate optional loopback-lab procedure.
Without a lab
The cards provide the names, byte counts, requests, responses, and stored records needed for the activity. Make a prediction and compare with the supplied reasoning; a practical run can wait. Reading works without JavaScript. Answer checking needs JavaScript and a secure context, normally HTTPS or a local preview. Saving additionally needs usable browser storage.

After this lesson you can:

  • Identify the name attribute as the submitted key.
  • Leave a disabled control out of the predicted body.
  • Place urlencoded data in the query for GET and in the body for POST.

01Example

The worked control displays the label Note, but its name attribute is note. With the initial value unchanged, the submitted pair is note=hello. The text after the label is a prediction, not a captured browser request. The surrounding sample form uses POST.

<label>Note <input name="note" value="hello"></label>

Predicted POST body
note=hello

02The name that is submitted

When a form is submitted, the browser constructs an entry list of names and values. For these text controls, a disabled control is omitted. A missing or empty name also means no entry. A label describes the control to the reader but does not supply the submitted key.

Serialization turns the entries into a representation suitable for sending. These forms use the default application/x-www-form-urlencoded format, a named rule for writing each name=value pair. It uses percent-encoding where required: @ is the byte 40 in hex, so [email protected] becomes ada%40example.invalid. Spaces use + in this particular format.

For this ordinary POST form, the serialized data goes in the request body. With GET, it goes in the URL query, the part after ?. Choosing POST does not encrypt the data; HTTPS provides connection protection. The supplied .html file can be read as source without creating any HTTP submission.

Map the control name/value to serialized data and method placement; GET/POST placement does not provide encryption.Model. A teaching model drawn by hand. It shows the idea, not real tool output.

Read the full explanation below.

Playback is optional. Step through at your own pace.

Worked POSTExplicitly hypothetical GETDeclared email encoding prediction

Control source

Notedisplay labelDisplay label, not the submitted key.
name="note"submitted keySubmitted key: note.
value="hello"worked value
<label>Note <input name="note" value="hello"></label>immutable worked source
[email protected]separate declared encoding prediction

Serialized name/value

note=hellopredicted form-urlencoded data
note=ada%40example.invalidpredicted encoding

Method and placement

POST body: note=hellobody placement
GET query: ?note=hellohypothetical query placement

Note is the display label; note from name is the submitted key.

Follow the explanation

  1. Note is the display label; note from name is the submitted key.
  2. The supplied control predicts POST body note=hello.
  3. For the hypothetical GET variant, the same pair appears after ? in the query.
  4. The separate declared value [email protected] predicts note=ada%40example.invalid.
Read every state and value

1. Note is the display label; note from name is the submitted key.

Example
post
Visible Item
<label>Note <input name="note" value="hello"></label> · Note · name="note" · value="hello"
Current mappings
None
Annotations
Item: Note; Text: Display label, not the submitted key. · Item: name="note"; Text: Submitted key: note.

2. The supplied control predicts POST body note=hello.

Example
post
Visible Item
<label>Note <input name="note" value="hello"></label> · Note · name="note" · value="hello" · note=hello · post
Current mappings
name supplies the key; value supplies data · POST worked body
Annotations
None

3. For the hypothetical GET variant, the same pair appears after ? in the query.

Example
get
Visible Item
<label>Note <input name="note" value="hello"></label> · Note · name="note" · value="hello" · note=hello · get
Current mappings
name supplies the key; value supplies data · Hypothetical GET query
Annotations
Item: get; Text: No request is submitted and no body is claimed.

4. The separate declared value [email protected] predicts note=ada%40example.invalid.

Example
email
Visible Item
<label>Note <input name="note" value="hello"></label> · Note · name="note" · value="hello" · email · note=ada%40example.invalid
Current mappings
Form-urlencoded prediction escapes @ as %40
Annotations
Item: note=ada%40example.invalid; Text: Predicted form-urlencoded serialization; no transmission.
Map the control name/value to serialized data and method placement; GET/POST placement does not provide encryption.

03Map a second form

Use the second form as new evidence. Its visible label is Drop box, its enabled field name is bin, and a separate field is disabled. Trace only the entries that would be submitted.

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Owned form card</title>
</head>
<body>
<p>Original fictional markup. Opening this file reads the markup. It does not submit an HTTP request.</p>
<form action="/note" method="post">
<p><label>Note <input name="note" value="hello"></label></p>
</form>
<form action="/bin" method="post">
<p><label>Drop box <input name="bin" value="slip"></label></p>
<p><label>Spare <input name="spare" value="idle" disabled></label></p>
</form>
</body>
</html>

Download the form markup

Original fictional predictions. No form was submitted. No server was started.

Worked POST, from the first form
Method: POST
Body: note=hello
The label is Note. The submitted key is the name attribute.

Activity POST, from the second form
Method: POST
Body: bin=slip
spare is disabled, so it is absent from the body.
Check: bin

Encoding prediction, still on the worked control
Value [email protected]
Predicted body: note=ada%40example.invalid
This applies the form-urlencoded serializer. It was not produced by a browser.

GET placement, if the worked form method were get
The same serializer output would be the query.
The body would not hold it.
That method change is not the activity form.

Download the predicted requests

  1. Find the form with action /bin and method post. Identify the label Drop box, name bin, and value slip as different roles.
  2. Build the entry bin=slip. Find spare=idle in the disabled control and explain why it does not become a second entry.
  3. Compare with the predicted request card: POST body bin=slip. Then read the separate worked encoding example note=ada%40example.invalid; it illustrates the format, not a changed value in the activity form.
  4. Stop with the predicted method, destination, and body. No server or form submission is needed; opening a local file is not evidence of an HTTP exchange.

04Optional challenge

Spend about ten extra minutes changing the worked form’s method to GET in notes. Its serialized pair would be in the query, as /note?note=hello, with no form-data body in this example. Explain which part moved and why this change does not make the data secret.

05Fresh cases for the checks

Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.

Form case A: fresh controlsOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.

<form method="post" action="/deliver">
<label>Destination <input name="tray" value="west hall"></label>
<input name="pin" value="9999" disabled>
<input value="unkeyed">
</form>
No values are edited. Use application/x-www-form-urlencoded: spaces become +. Omit disabled and unnamed text controls.

Form case B: independent changed methodOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.

<form method="get" action="/search">
<input name="tag" value="blue@club">
</form>
Use application/x-www-form-urlencoded: @ becomes %40. No other form entries exist.

06Explain your prediction

Optional written self-check: Explain the label/name distinction, omitted controls, serialization and query/body placement. Show why URL encoding and POST alone do not provide the connection protection supplied by HTTPS.

07Common mistakes

If you submit Drop box as the key, compare the label text with the name attribute. The entry uses bin.

If you include spare=idle, check the disabled attribute before constructing the list. The sample’s disabled control is omitted.

If the local HTML file is described as a completed HTTP request, separate source reading from submission. The request card is a prediction of a later operation.

References