[rmunn]

1. Sometimes you need a request body. 2. POST cannot be guaranteed to be safe if re-sent. 3. This is GET with a request body, guaranteed* to be safe if re-sent.

* With the caveat that it's only guaranteed if the server is following the RFC correctly.

[LaGrange]

I will keep using POST and not some weird thing that isn’t supported by a proxy living in the basement of a shoe store in Wageningen or whatever.

[PunchyHamster]

> POST cannot be guaranteed to be safe if re-sent.

It can absolutely be guaranteed. What it can't be is communicated to be safe so browser gonna ask its silly question

[broken-kebab]

You can guarantee it to yourself, sure, but the talk is about different guarantees, those which are implied by people who has no idea about your plans and opinions but whose software may interact with yours.

[hparadiz]

I read the RFC front to back. It is lazy. To the point where I'd be embarrassed to even show it to people.

For one you would never allow a client to dictate the query. That is a security and validation problem. So you have to deconstruct the query anyway and then rebuild it. That's HTTP APIs 101. Now if the authors of this RFC knew what they were doing they could enforce trust with some sort of JWT like trust mechanism but no they don't bother to define ANYTHING like that. Instead and I will quote this for completeness because it's honestly one of the funniest things I've ever read in an RFC.

> 4. Security Considerations

> It can be used as an alternative to passing request information in the URI (e.g., in the query component). This is preferred in some cases, as the URI is more likely to be logged or otherwise processed by intermediaries than the request content. In other cases, where the query contains sensitive information, the potential for logging of the URI might motivate the use of QUERY over GET.

This. This is just plain baffling to me. The argument is that QUERY replaces GET (it doesn't) so let's shove data into the same place that POST already does because it MAY MAY be logged. Bro the people doing the logging are logging the entire damn thing URI, Header, and Body. What even is this.

And again if they knew their shit they would know that GET has a soft cap of 2,083 characters from the internet explorer days so no one shoves more than that into a url for compatibility and if they do they risk losing data so they use POST anyway. Heck my framework even does JSON post bodies in the POST. And again if you are writing an RFC do your research and use this technical fact as an advantage. Define your own limits and explain why based on existing methodology. It would actually give your RFC some weight.

It doesn't even bother to address query feedback errors like what if the disk says no and writes are locked.

Frankly...... I miss the old days when RFCs where measured in pounds of paper.

[flanked-evergl]

> For one you would never allow a client to dictate the query. That is a security and validation problem. So you have to deconstruct the query anyway and then rebuild it.

Every single SQL server allows a client to dictate the query. Furthermore, not all queries are SQL queries.

[antiloper]

Yes servers have to validate input data... This isn't new...