The browser address bar performs GET requests, so I think the answer is "you can't bookmark or share QUERY requests," same as with POST requests.

However, just as with POST requests, it might make sense for the server to respond with a redirect to a URL that could be shared.

In HTTP, clients are user agents and a web browser is only one kind of user agent that is specialized in fetching and displaying web pages. Like PUT and DELETE, this is clearly meant for APIs, not web pages. (Although sufficiently "advanced" web pages may make API calls.)

It's more for the SPA age of web apps, where we want to GET a resource from an API, but have a body in the request. For example fetching the user who is currently logged in and getting a JSON response back; it's not something you would do in the address bar.

I'm not sure it makes sense for an HTTP protocol method standard to describe how browsers should allow it's input in the URL bar - two very different standards realms.

That said you should be able to trigger any custom HTTP request your browser support via pasting/bookmarking a `data:` or `javascript:` construction if you really want. As of now the URL bar is GET only when you enter a URL.

> I'm not sure it makes sense for an HTTP protocol standards to describe how browsers should allow it's input in the URL bar - two very different standards realms.

Just as a small remark, HTTP protocol standards do - or have at least - considered URL input so far in a wider, client-side meaning. Some details are left for the clients, e.g. it differs across browsers how certain URL characters are interpreted when entered into the URL bar (or on the command-line, e.g. with curl(1)).

Apart from that, HTTP URLs are part of the same HTTP standard, aren't they?

HTTP URLs and HTTP methods are two very different things, somewhat conflated in that the browser treats URLs in the URL bar as a shorthand for generating a GET. While URL encodings are well standardized for general use in RFCs the parsing into an HTTP GET when entered into the URL bar is not, it's just good UI. The same would be said about the QUERY method standard, it's not about describing how the browser UI should allow making such a request header just what a valid one is.

same as with POST: not really intended for that case.

Similarly to as if you were using POST requests I'd say. So if you want the users to be able to navigate to a URL and get the same results for a POST request, you'd make the client-side read URL parameters and sculpt the POST request and send it.

probably same as with POST, that is not at all