Remix.run Logo
Joker_vD 6 hours ago

> It also implies an unbounded and user-controlled cache key,

The query part of GET's URI is also barely bounded in practice and user-controlled, and is indeed used as part of the cache key (because it's a part of URI), so I am not sure why you raise this objection at all.

giancarlostoro 6 hours ago | parent | next [-]

> and user-controlled

I've found some sites that tack on a session ID and if you try to tamper with the URL in any way, it sends you back to "Page 1" really annoys me lol at that point let me skip to any page with your web UI.

PunchyHamster 5 hours ago | parent | prev [-]

Well, because it is more code. Current caching software caches by headers + query string. It now needs to be expaned to cache by body too.

It feels very pointless and there is no drawback of just using POST

OvervCW 4 hours ago | parent | next [-]

There is: your browser or other type of client does not know it can repeat a POST request if it fails, whereas a QUERY request can be freely repeated in case of errors.

afavour 5 hours ago | parent | prev [-]

Is caching not the primary reason to use this over POST? You should never want to cache POST requests.