4 ms·

It's still a bad idea. It has no defined semantics, meaning that servers, clients, proxies and anything else are free to ignore or drop it. It also defeats cac

by treve 12y ago

It's still a bad idea. It has no defined semantics, meaning that servers, clients, proxies and anything else are free to ignore or drop it. It also defeats caching and any other reasons why you would want to use GET over some other http requests. I would argue that the only reason left why you would use GET for that, is because it's aesthetically pleasing.

xxs 12y ago
My thoughts exactly - GET with payload virtually means no caching.
- masklinn 12y ago
  If you've got to use body payloads, requests are probably way too big and unique for the involvement of caches browser or intermediate caches to be a good idea.
masklinn 12y ago
> I would argue that the only reason left why you would use GET for that, is because it's aesthetically pleasing. Not all systems support practically unlimited URI payloads[0]. In the past, this forced either contorsion (gzipping URI payload) or piping everything through POST. For instance, let's say you've built a music identification system, people can send in files and get information about the file's data. This is a purely readonly request, the backend just uses its information to identify the file and fetch whatever data and metadata on the file's content it has. But historically there was no choice but to route it via a semantically unsuitable POST. [0] Apache defaults to 8190 bytes, IIS to 16384, Safari and Firefox support >100k but MSIE is limited to 2048
- nileshtrivedi 12y ago
  Another example: Searching for images similar to a specified one.
  - masklinn 12y ago
    A great example, image search already being fairly common (and being useful to all sorts of purposes)
gioele 12y ago
> It also defeats caching and any other reasons why you would want to use GET over some other http requests. It does not break caching. Instead of just using the URL as the caching key, use URL+body. Same URL and same body = same response.
- thegregjones 12y ago
  Do any caches operate like that?
  - RobAley 12y ago
    Not many I would think. For compatibility with existing caches, you could do something like add an extra parameter to the URL with a hash of the message body. In the case of e.g. an image or music file given elsewhere in this thread, the cache doesn't actually need the full contents of the image file (like the backend does), just something like a hash to match it to a previous request.
- dragonwriter 12y ago
  > Instead of just using the URL as the caching key, use URL+body. Same URL and same body = same response. Well, except that since the body isn't defined as having semantics that determine the response, an cache based on the HTTP protocol spec has no reason to do that.
  - ajanuary 12y ago
    Talking from a practical standpoint, to try and have GET requests with large parameters you could put the data in the message body, and then a hash of the message in the URL to avoid caching issues.

by treve 12y ago

xxs 12y ago

My thoughts exactly - GET with payload virtually means no caching.

masklinn 12y ago
If you've got to use body payloads, requests are probably way too big and unique for the involvement of caches browser or intermediate caches to be a good idea.

masklinn 12y ago

> I would argue that the only reason left why you would use GET for that, is because it's aesthetically pleasing. Not all systems support practically unlimited URI payloads[0]. In the past, this forced either contorsion (gzipping URI payload) or piping everything through POST. For instance, let's say you've built a music identification system, people can send in files and get information about the file's data. This is a purely readonly request, the backend just uses its information to identify the file and fetch whatever data and metadata on the file's content it has. But historically there was no choice but to route it via a semantically unsuitable POST. [0] Apache defaults to 8190 bytes, IIS to 16384, Safari and Firefox support >100k but MSIE is limited to 2048

nileshtrivedi 12y ago
Another example: Searching for images similar to a specified one.
- masklinn 12y ago
  A great example, image search already being fairly common (and being useful to all sorts of purposes)

gioele 12y ago

> It also defeats caching and any other reasons why you would want to use GET over some other http requests. It does not break caching. Instead of just using the URL as the caching key, use URL+body. Same URL and same body = same response.

thegregjones 12y ago
Do any caches operate like that?
- RobAley 12y ago
  Not many I would think. For compatibility with existing caches, you could do something like add an extra parameter to the URL with a hash of the message body. In the case of e.g. an image or music file given elsewhere in this thread, the cache doesn't actually need the full contents of the image file (like the backend does), just something like a hash to match it to a previous request.
dragonwriter 12y ago
> Instead of just using the URL as the caching key, use URL+body. Same URL and same body = same response. Well, except that since the body isn't defined as having semantics that determine the response, an cache based on the HTTP protocol spec has no reason to do that.
- ajanuary 12y ago
  Talking from a practical standpoint, to try and have GET requests with large parameters you could put the data in the message body, and then a hash of the message in the URL to avoid caching issues.