3 ms·

I think this was a situation where either choice (extend GET, create QUERY) was less then ideal but at least if you create a new namespace in QUERY you can avoi

I think this was a situation where either choice (extend GET, create QUERY) was less then ideal but at least if you create a new namespace in QUERY you can avoid arcane business logic around GET by various caches, loadbalancers, proxies, and other software that made who knows what terrible assumptions around GET payload shape.

akersten 5y ago
> you can avoid arcane business logic around GET by various caches, loadbalancers, proxies, and other software that made who knows what terrible assumptions around GET payload shape. I wish standards bodies weren't afraid of angering the feet-dragging vendors who haven't had to update their shitty middleboxes in 20 years despite charging their customers through the nose for them. Maybe it would be better for a healthier web if these dinosaur machines got broken once in a while.
- toomuchtodo 5y ago
  There is enormous spend and investment that occurs under low volatility assumptions. People don't want their gear to break for features they may not want or need (see: IPv6 uptake, Python 2->3 migration timelines if at all, etc). Standards bodies exist to serve users, not the other way around. Balance backwards compatibility with forward velocity.
- shadowgovt 5y ago
  It's all fun and games until it turns out your home ISP is one of those dinosaur machines and now you can't log onto HN because none of the routers you can connect to understand GET with a body.
  - ithkuil 5y ago
    In that case you'd be using https which doesn't get proxied. But yeah, it's all somebody else's problem until it's yours...
- will4274 5y ago
  If standards bodies ignored compatibility, it's not the middle boxes that would become irrelevant. It'd be the standards that became irrelevant.
- threeseed 5y ago
  > Maybe it would be better for a healthier web if these dinosaur machines got broken once in a while. I would expect that the majority of all GET requests are non public-facing. So needlessly breaking all of these machines would have little to no user benefit.

akersten 5y ago

> you can avoid arcane business logic around GET by various caches, loadbalancers, proxies, and other software that made who knows what terrible assumptions around GET payload shape. I wish standards bodies weren't afraid of angering the feet-dragging vendors who haven't had to update their shitty middleboxes in 20 years despite charging their customers through the nose for them. Maybe it would be better for a healthier web if these dinosaur machines got broken once in a while.

toomuchtodo 5y ago
There is enormous spend and investment that occurs under low volatility assumptions. People don't want their gear to break for features they may not want or need (see: IPv6 uptake, Python 2->3 migration timelines if at all, etc). Standards bodies exist to serve users, not the other way around. Balance backwards compatibility with forward velocity.
shadowgovt 5y ago
It's all fun and games until it turns out your home ISP is one of those dinosaur machines and now you can't log onto HN because none of the routers you can connect to understand GET with a body.
- ithkuil 5y ago
  In that case you'd be using https which doesn't get proxied. But yeah, it's all somebody else's problem until it's yours...
will4274 5y ago
If standards bodies ignored compatibility, it's not the middle boxes that would become irrelevant. It'd be the standards that became irrelevant.
threeseed 5y ago
> Maybe it would be better for a healthier web if these dinosaur machines got broken once in a while. I would expect that the majority of all GET requests are non public-facing. So needlessly breaking all of these machines would have little to no user benefit.