Hacker News Reader

>redefine GET as having a semantic body because a bazillion different implementations (clients, servers and middle boxes) probably become non-compliant.

So what actually?

apps that didnt use GET Body, will not care anyway

apps that will use HTTP GET Body will be checked anyway

So, unless somebody downgrades HTTP Server then what could be the problem?

View on HN

Many, many services (most of the internet?) has the backend sitting behind a proxy that would throw away the payload before it gets to the "apps".

Granted they need to get support for QUERY too but at least it is more explicit then.

An official readonly flag to POST would have been more backwards compatible...

Aside from how much easier it is to identify whether a component supports QUERY than which forms of GET it supports, GET and QUERY (like PUT and DELETE) have similar guarantees have different meaning and are sometimes (but not always) useful against the same resource for different purposes. OPTIONS lets you tell the availability of that of they are different methods, but not if one is GET w/o body and the other is GET w/body.

Reply on news.ycombinator.com