Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Upcoming new HTTP QUERY method

datatracker.ietf.org

Post reply on HN
Print view View original

51–60 of 79 posts

Re: Upcoming new HTTP QUERY method

#51

Post by capableweb »

dragonwriter wrote: post #44
capableweb wrote: post #35

Earlier quoted context omitted.

> 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/288308 , https://www.kb.cert.org/vuls/id/150227 ) for some…

> > the 7 existing http verbs > 9 to be precise You are off by 30: https://www.iana.org/assignments/http-methods/http-methods.x...

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)

Re: Upcoming new HTTP QUERY method

#52

Post by toomuchtodo »

akersten wrote: post #46
tmp_anon_22 wrote: post #19

Earlier quoted context omitted.

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.

> 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 health…

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.

Re: Upcoming new HTTP QUERY method

#53

Post by will4274 »

akersten wrote: post #46
tmp_anon_22 wrote: post #19

Earlier quoted context omitted.

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.

> 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 health…

If standards bodies ignored compatibility, it's not the middle boxes that would become irrelevant. It'd be the standards that became irrelevant.

Re: Upcoming new HTTP QUERY method

#54

Post by dragonwriter »

elcapitan wrote: post #12

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 que…

> 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.

Re: Upcoming new HTTP QUERY method

#55

Post by elcapitan »

dragonwriter wrote: post #44
capableweb wrote: post #35

Earlier quoted context omitted.

> 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/288308 , https://www.kb.cert.org/vuls/id/150227 ) for some…

> > the 7 existing http verbs > 9 to be precise You are off by 30: https://www.iana.org/assignments/http-methods/http-methods.x...

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.

Re: Upcoming new HTTP QUERY method

#56

Post by shadowgovt »

akersten wrote: post #46
tmp_anon_22 wrote: post #19

Earlier quoted context omitted.

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.

> 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 health…

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.

Re: Upcoming new HTTP QUERY method

#59

Post by afiori »

n00bskoolbus wrote: post #41
hcarvalhoalves wrote: post #34

> This specification defines the HTTP QUERY request method as a means of making a safe, idempotent request that contains content. I’m already seeing implementors failing at following the spec here – they will equate the QUERY method to querying a mutable database, which won’t give reproducible results, and to give reproducible results the server would need to save it. Now to make it idempotent, will be an ad-hoc deci…

Yeah it's already created confusion for me. I read it as essentially a side effect free request with a request body. Not that the data behind it was necessarily immutable but that the query didn't do any mutations.

Idempotent is not "side effect free", but rather with only side effects that need to be safe to duplicate and deduplicate.

As in "increase counter by 1" is not idempotent, "set counter to 2" and "set counter (monotonic*) counter to 2 if current value is 0" are idempotent.

It is quite weak as a requirement for example an API that functionally must not be cached can still be idempotent.

Re: Upcoming new HTTP QUERY method

#60

Post by emmanueloga_ »

bullen wrote: post #39

Sometimes reality beats fiction: http://rupy.se/doc/ I chose Query.java as the class name for my combined GET/POST container back in 2008: https://github.com/tinspin/rupy/blob/master/src/se/rupy/http... Back then it was hosted on google code.

btw, why is it called "rupy" ?
Post reply on HN