You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be awesome to be able to cache some POST requests (ex: product filters etc) and I get why they are bypassed by default. But would you be open to the idea of adding a header that would allow caching of POST?
Best regards
The text was updated successfully, but these errors were encountered:
Just my 2 cents: I think that the use cases for caching POST requests are so few and so specific that would not make to much sense to implement in a generic container like wodby/varnish
@esolitos both servers and clients have a max size of GET request lengths. The server size could simple be adjusted but we cannot control the allowed size of the client (I think the safest size is still 2KB; even though it has been a few years since I last researched it). Because of this alone, sometimes, what could have been GET requests, is being executed as POST requests instead to make sure. And in my mind, if you have requests that are bigger than 2KB, then they must be pretty heavy as well, so these could be pretty awesome to be able to cache.
There are very few ecommerce solutions today that do not offer products filters, to mention a specific example.
The case also becomes extra obvious in the WordPress would where a lot of times the values passed around are slugs/machine-names instead of simple ids, so the size of a GET request can quickly build up. product-type=231,5,23,543 => product-type=plane-tshirts,winter-jackets,womens-skirts,miscellaneous-sunglasses.
It would be awesome to be able to cache some POST requests (ex: product filters etc) and I get why they are bypassed by default. But would you be open to the idea of adding a header that would allow caching of POST?
Best regards
The text was updated successfully, but these errors were encountered: