3 ms·

Two things that come to my mind: - why not just extend GET to make a payload not "undefined" anymore? Instead now people have to wonder whether to use GET or Q

Two things that come to my mind: - why not just extend GET to make a payload not "undefined" anymore? Instead now people have to wonder whether to use GET or QUERY. The non-idempotent methods have at least a difference in semantics, while this here seems mostly another way to provide parameters for essentially the same action. - QUERY is a somewhat bad name choice, given that URL parameters are also refered to as query string

tmp_anon_22 5y ago
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.
deleted 5y ago
[deleted]
oh_sigh 5y ago
I wondered the same thing. Perhaps it is easier to roll out a new request method, rather than increase the scope of an existing request method. For example, a lot of extant middleware might silently drop a GET requests body, whereas they would just error out upon seeing "QUERY ..."
- dragonwriter 5y ago
  > Perhaps it is easier to roll out a new request method, rather than increase the scope of an existing request method. It’s easier to define semantics for a new method than to expect everyone to change how an existing methods is handled by all existing software.
  - nieve 5y ago
    And it is often easier to argue that software should add support for a new method than that it should change semantics that other users/customers may depend on even if those semantics aren't ideal.
deleted 5y ago
[deleted]
capableweb 5y ago
> - QUERY is a somewhat bad name choice, given that URL parameters are also refered to as query string Slightly confusing, I agree. But given that neither are called just "query", and HTTP methods being usually in all caps, I think it won't be as bad. "Query component" (from URIs as specced) VS "QUERY method" should be clear enough.
clairity 5y ago
either extension method seems a lost cause, given that most browsers/web servers don't fully support the 7 existing http verbs, even with decades to do so.
- capableweb 5y ago
  > don't fully support the 7 existing http verbs 9 to be precise (RFC 7231 defines GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, RFC 5789 defines PATCH). Some of those are not commonly used because of various security vulnerabilities that have been discovered over the years (see https://www.kb.cert.org/vuls/id/867593 https://www.kb.cert.org/vuls/id/867593, https://www.kb.cert.org/vuls/id/288308 https://www.kb.cert.org/vuls/id/288308, https://www.kb.cert.org/vuls/id/150227 https://www.kb.cert.org/vuls/id/150227) for some examples. Some tooling goes as far as defining some of those methods as "forbidden", like what the standard for JavaScript Fetch does.
  - dragonwriter 5y ago
    > > the 7 existing http verbs > 9 to be precise You are off by 30: https://www.iana.org/assignments/http-methods/http-methods.xhtml https://www.iana.org/assignments/http-methods/http-methods.x...
    - elcapitan 5y ago
      A lot of these seem to be specific to e.g. WebDAV though, hardly general purpose HTTP methods. God knows why they had to muddle this up like that.
      - clairity 5y ago
        yah, i should have specified 'common' or 'web', or something like that. i had a feeling someone would raise a more technically precise but also more esoteric rebuttal.
    - capableweb 5y ago
      Oh, I did not know about that! You learn something new every day at HN :) Thanks! Granted, I guess you could argue that because you can use whatever method you want in practice, there is a unlimited set of methods available (depending on how long string whatever server you're using could create, if they are parsing it and so on)
bricss 5y ago
GET with "Query" header + "Vary: Query" header, might be a thing to get escape from the cache dungeon
tomcam 5y ago
> QUERY is a somewhat bad name choice, given that URL parameters are also refered to as query string That has always driven me crazy
darau1 5y ago
I've used VIEW for this kind of thing. I don't even know what VIEW is for
teen 5y ago
Seems nice to me.
dragonwriter 5y ago
> QUERY is a somewhat bad name choice, given that URL parameters are also refered to as query string SEARCH and REPORT, which are probably better names, were already taken by WebDAV, a pre-REST style protocol layered over HTTP that loved (loves?) registering new HTTP methods.

tmp_anon_22 5y ago

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.

deleted 5y ago

[deleted]

oh_sigh 5y ago

I wondered the same thing. Perhaps it is easier to roll out a new request method, rather than increase the scope of an existing request method. For example, a lot of extant middleware might silently drop a GET requests body, whereas they would just error out upon seeing "QUERY ..."

dragonwriter 5y ago
> Perhaps it is easier to roll out a new request method, rather than increase the scope of an existing request method. It’s easier to define semantics for a new method than to expect everyone to change how an existing methods is handled by all existing software.
- nieve 5y ago
  And it is often easier to argue that software should add support for a new method than that it should change semantics that other users/customers may depend on even if those semantics aren't ideal.

deleted 5y ago

[deleted]

capableweb 5y ago

> - QUERY is a somewhat bad name choice, given that URL parameters are also refered to as query string Slightly confusing, I agree. But given that neither are called just "query", and HTTP methods being usually in all caps, I think it won't be as bad. "Query component" (from URIs as specced) VS "QUERY method" should be clear enough.

clairity 5y ago

either extension method seems a lost cause, given that most browsers/web servers don't fully support the 7 existing http verbs, even with decades to do so.

capableweb 5y ago
> don't fully support the 7 existing http verbs 9 to be precise (RFC 7231 defines GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, RFC 5789 defines PATCH). Some of those are not commonly used because of various security vulnerabilities that have been discovered over the years (see https://www.kb.cert.org/vuls/id/867593 https://www.kb.cert.org/vuls/id/867593, https://www.kb.cert.org/vuls/id/288308 https://www.kb.cert.org/vuls/id/288308, https://www.kb.cert.org/vuls/id/150227 https://www.kb.cert.org/vuls/id/150227) for some examples. Some tooling goes as far as defining some of those methods as "forbidden", like what the standard for JavaScript Fetch does.
- dragonwriter 5y ago
  > > the 7 existing http verbs > 9 to be precise You are off by 30: https://www.iana.org/assignments/http-methods/http-methods.xhtml https://www.iana.org/assignments/http-methods/http-methods.x...
  - elcapitan 5y ago
    A lot of these seem to be specific to e.g. WebDAV though, hardly general purpose HTTP methods. God knows why they had to muddle this up like that.
    - clairity 5y ago
      yah, i should have specified 'common' or 'web', or something like that. i had a feeling someone would raise a more technically precise but also more esoteric rebuttal.
  - capableweb 5y ago
    Oh, I did not know about that! You learn something new every day at HN :) Thanks! Granted, I guess you could argue that because you can use whatever method you want in practice, there is a unlimited set of methods available (depending on how long string whatever server you're using could create, if they are parsing it and so on)

bricss 5y ago

GET with "Query" header + "Vary: Query" header, might be a thing to get escape from the cache dungeon

tomcam 5y ago

> QUERY is a somewhat bad name choice, given that URL parameters are also refered to as query string That has always driven me crazy

darau1 5y ago

I've used VIEW for this kind of thing. I don't even know what VIEW is for

teen 5y ago

Seems nice to me.

dragonwriter 5y ago

> QUERY is a somewhat bad name choice, given that URL parameters are also refered to as query string SEARCH and REPORT, which are probably better names, were already taken by WebDAV, a pre-REST style protocol layered over HTTP that loved (loves?) registering new HTTP methods.