h a l f b a k e r yThere goes my teleportation concept.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Our browsers do not send a POST request explicitly via address line.
So,
whenever we
try to open a web page by URL, we always are sending GET (?
some=data)
requests. But what about updating data on resources? Introducing the
POST
(!=some&data).
For example, if we chose this symbol to
be "!", then, if you want to
mutate
data on an endpoint, you'd simply query your browser address by a link:
http://example.net/endpoint!param=val
And visiting it, the browser would send a POST header to the endpoint,
serializing data for the body from its URL parameters.
Wikipedia
https://en.wikipedi...ubmitting_web_forms
(POST) html [FlyingToaster, Oct 29 2019]
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Destination URL.
E.g., https://www.coffee.com/
Description (displayed with the short name and URL.)
|
| |
The Wikipedia article on POST contains the line "when a browser sends a POST request..." |
|
| |
Which version of Wikipedia article? [FlyingToaster] |
|
| |
<linked> : I don't know anything about the subject, myself, mind. |
|
| |
You can easily manipulate POST data using the dev tools built-in to almost all browsers. |
|
| |
Putting POST data in a URL completely defeats the point of it. Why do you think there is a distinction to begin with? It wasn't for lack of a good choice of syntax. |
|
| |
Some things you might want to think about: |
|
| |
- Passwords sent as POST data appearing in server logs and browser histories |
|
| |
- Large amounts of form data making URLs too long and getting truncated by some systems |
|
| |
- Leaking POST data via HTTP-referrer |
|
| |
Well, I suppose the distinction obviously is to separate the I/O as !/?, the
MUTATE and FILTER types of queries. POST and GET. With GET
requests we were supposed to FILTER/SEARCH the web entities, and
with POST requests we were supposed to CREATE/MODIFY the web
entities. |
|
| |
Regarding privacy/security, this would not suffer, as it would not appear
in the logs, if implemented on the browser side as a convenience for
user to use the ! to do POST requests. |
|
| |
However, that would of course break the consistency of the browsers,
that we have, where whatever is in the URL, is just doing GET requests.
Therefore, a different color (just like the HTTPS indicator) would have to
highlight, whenever what is to be run, is a POST
request. In addition, it would probably be great to simply let the browser
users to have a consistent button or drop-down in
the link, to choose, what type of request they want to make, without
having to open developer tools. |
|
| |
Today, I suppose there exists an ambiguity such that, under legal
circumstances, you can perfectly say that you opened a link, and saw a
completely different content, because you made a POST request by
opening it, not the GET. |
|
| |