h a l f b a k e r y"It would work, if you can find alternatives to each of the steps involved in this process."
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]
[link]
|
| |
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. |
|
| |