../courses.php

The Browser's Role

BROWSER

90

Sending A Request To A Server

Why the method on a request matters more than what a button happens to be labeled.

Two buttons on the same page are both labeled "Submit." Clicking one changes nothing about the user's account and is perfectly safe to click twice by accident. Clicking the other deletes a record permanently, and clicking it twice by accident deletes two records. Both buttons say the exact same word. What actually decided how dangerous each click is?

A button's label is just text for a person to read. What a click actually does depends on the request the underlying form is built to send, specifically its method and its destination, neither of which is visible in the label at all. A GET request is meant to only ask for something, with no expectation it changes anything if repeated. A POST request, by contrast, is commonly used specifically for actions that do change something, which is exactly why one of these two identically labeled buttons is safe to double-click and the other is not.

Every request a browser sends carries a method, stating what kind of action is intended, alongside the address being requested. GET and POST are the two methods relevant to this course, though more exist.

GET requests are meant to only retrieve something, with no expectation that sending the same one twice causes any additional change. POST requests are commonly used specifically when an action is meant to create, change, or remove something.

A request also carries headers, separate from its address and body, holding extra information such as what kind of content is being sent or what language the browser prefers to receive a response in.

A GET request has no separate body at all, since the values it carries already sit inside the address itself. A POST request carries its values in a separate body, apart from the address.

Nothing about the method itself is enforced by the browser as a safety rule. A website is free to wire a destructive action to a GET request, against the convention, and the browser will send it exactly the same way regardless.

Two requests with the same address, different methods

This GET request asks only for a report, with month=march carried directly inside the address. Sending this exact same request five times in a row asks for the exact same report five times, with no additional effect each time.

This request's address, /reports/delete, and its method together describe an action meant to delete something. The body, id=4471, is sent separately from the address, specifying which one record.

Content-Length states exactly how many characters the body contains, 11 for id=4471. A server reads exactly that many characters as the body and nothing more, which is why this number has to match the body's real length precisely.

Sending the GET request again is harmless, by the convention this method is meant to follow. Sending the exact same POST request again would attempt to delete the same record a second time, which may produce an error the second time, or, on a server that does not check carefully, attempt the deletion again regardless.

Nothing about the browser itself treated these two requests differently in terms of safety. The distinction exists only because whoever built the page chose to wire the delete action to a POST request, following the convention that GET should stay safe to repeat.

A method is a stated intention, not an enforced rule

Nothing prevents a website from wiring a destructive action to a GET request. The browser sends a GET request exactly the way it sends any other, with no built-in safety check based on the method, which is why following the GET-is-safe-to-repeat convention is a choice made by whoever builds a site, not a guarantee from the browser itself.

A search engine or browser preloading a page can trigger a GET request the user never directly asked for

Because GET requests are meant to be safe to repeat with no side effects, tools such as search engine crawlers and browser preloading features will follow GET links freely. A destructive action wired to a GET request risks being triggered by exactly this kind of automatic, non-human request.

A wrong Content-Length can cut a request's body short or read into the next one

A body that is actually 11 characters long, declared with a smaller Content-Length, can be read by some servers as only that many characters, silently losing the rest, rather than producing an obvious, visible error pointing at the mismatch.

GET puts data in the address, where it can end up logged, bookmarked, or shared

Values carried in a GET request's address become part of the visible URL, which can be saved in browser history, server logs, and bookmarks, and can be accidentally shared if a user copies the address. This is a specific, practical reason sensitive values belong in a POST body instead.

Resubmitting a POST request is a real, common source of duplicate actions

A user clicking a submit button twice, or pressing the browser's back button and resubmitting a form, can send the exact same POST request a second time. This is the specific, mechanical reason behind warnings some browsers show before resubmitting a form.

Wiring a delete action to a GET link

Wiring a delete action to a POST form

When an AI tool describes an action, three things are worth checking. First, does anything that creates, changes, or deletes something use a POST request rather than a GET link. Second, does the description account for automatic tools, such as crawlers or preloaders, potentially following any GET link freely. Third, does a request's stated Content-Length actually match the real length of its body.

Change the delete link in bad_code into an actual clickable link on a test page, and explain what a search engine crawler following every link on that page would end up doing.

Send this lecture's GET request three times in a row, and confirm nothing about the report itself changes between attempts.

Deliberately set Content-Length to a number smaller than the real body, and read how a server you have access to behaves with the mismatched value.

Rewrite the delete action as a POST form instead of a GET link, matching the good_code example, and explain specifically what changes about how safely it can be linked to.

Find a real, working website with a feature that changes something through a plain GET link instead of a form, if one exists, and explain the practical risk of that specific design choice.

Wiring a destructive action, such as deleting or modifying something, to a GET request instead of a POST request.

Assuming the browser enforces some safety distinction between GET and POST, rather than only sending exactly what a page was built to send either way.

Setting a Content-Length value that does not exactly match a request body's real length.

Placing sensitive values, such as a password, into a GET request's address instead of into a POST request's separate body.

Assuming a resubmitted POST request, from a double click or a back-button resubmission, will always be safely ignored or rejected by the server receiving it.

You can now explain why GET and POST carry genuinely different expectations about repeating a request safely, and why that expectation is a convention websites choose to follow, not a rule the browser enforces. You can also identify where a request's values actually live, in the address for GET or in a separate body for POST, and why that difference has real consequences for safety and privacy.