The Stack Overflow podcast is back! Listen to an interview with our new CEO.
2 Clarification on query string parameter storage
source | link

Just to add to Thomas Pornin's answer, GET requests are subject to caching by proxy servers so you can't 100% guarantee that a GET request will make it to the target server and not get the response from a proxy. Yes you can add headers to specify that there is to be no caching, but not every proxy abides by the rules. Isn't it easier to use best practise and POST your updates? I can't see why you would want to use GET (apart from laziness). By using POST you are informing everything (browser / HTTP provider, proxy and server) that the request makes a "destructive" change and it should ensure your request is made appropriately without the need to manage any request headers.

Also, POST requests are less likely to have parameters logged so any sensitive parameters on the query string in a GET are not likely to be stored outside of your application's control such as in proxy or server logs (e.g. tokens) when made in the POST body instead. Again this isn't guaranteed, but by using the appropriate request method you are hinting at the intention of the request.

Just to add to Thomas Pornin's answer, GET requests are subject to caching by proxy servers so you can't 100% guarantee that a GET request will make it to the target server and not get the response from a proxy. Yes you can add headers to specify that there is to be no caching, but not every proxy abides by the rules. Isn't it easier to use best practise and POST your updates? I can't see why you would want to use GET (apart from laziness). By using POST you are informing everything (browser / HTTP provider, proxy and server) that the request makes a "destructive" change and it should ensure your request is made appropriately without the need to manage any request headers.

Also, POST requests are less likely to have parameters logged so any sensitive parameters on the query string are not likely to be stored outside of your application's control such as in proxy or server logs (e.g. tokens). Again this isn't guaranteed, but by using the appropriate request method you are hinting at the intention of the request.

Just to add to Thomas Pornin's answer, GET requests are subject to caching by proxy servers so you can't 100% guarantee that a GET request will make it to the target server and not get the response from a proxy. Yes you can add headers to specify that there is to be no caching, but not every proxy abides by the rules. Isn't it easier to use best practise and POST your updates? I can't see why you would want to use GET (apart from laziness). By using POST you are informing everything (browser / HTTP provider, proxy and server) that the request makes a "destructive" change and it should ensure your request is made appropriately without the need to manage any request headers.

Also, POST requests are less likely to have parameters logged so any sensitive parameters on the query string in a GET are not likely to be stored outside of your application's control such as in proxy or server logs (e.g. tokens) when made in the POST body instead. Again this isn't guaranteed, but by using the appropriate request method you are hinting at the intention of the request.

1
source | link

Just to add to Thomas Pornin's answer, GET requests are subject to caching by proxy servers so you can't 100% guarantee that a GET request will make it to the target server and not get the response from a proxy. Yes you can add headers to specify that there is to be no caching, but not every proxy abides by the rules. Isn't it easier to use best practise and POST your updates? I can't see why you would want to use GET (apart from laziness). By using POST you are informing everything (browser / HTTP provider, proxy and server) that the request makes a "destructive" change and it should ensure your request is made appropriately without the need to manage any request headers.

Also, POST requests are less likely to have parameters logged so any sensitive parameters on the query string are not likely to be stored outside of your application's control such as in proxy or server logs (e.g. tokens). Again this isn't guaranteed, but by using the appropriate request method you are hinting at the intention of the request.