Hacker News Reader

Comment by soheilpro | Hacker News Reader

From RFC 7231:

   A payload within a GET request message has no defined semantics;
   sending a payload body on a GET request might cause some existing
   implementations to reject the request.

View on HN

Right. The HTTP RFCs have been backing off gently from the initial position that implementations should not sent bodies with GETs and that the semantics of the GET request were defined purely in the request URI.

But presumably no-one is brave/foolhardy enough actually to redefine GET as having a semantic body because a bazillion different implementations (clients, servers and middle boxes) probably become non-compliant.

>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?

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.

Are they more or less likely to be compliant, though, than with a new verb?

Handling a method or not is a much more obvious thing to discover/observe.

Yea, that's what I meant

What if we allowed HTTP GET Body?

Reply on news.ycombinator.com