61–70 of 79 posts
Earlier quoted context omitted.
> > 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.
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" ?
I like short names and make computer games, Zelda (or maybe just me) misspelled rupie rupy.
I did not know about Ruby Python back then... now I feel it's too late... eventually I'll try and change the name to binarytask since I bought binarytask.com...
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…
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.
We should just create a revision for RFC 2616 to extend the GET method to allow request bodies. Most HTTP frameworks already support this behaviour anyway.
Earlier quoted context omitted.
I'm not sure it makes sense for an HTTP protocol method standard to describe how browsers should allow it's input in the URL bar - two very different standards realms. That said you should be able to trigger any custom HTTP request your browser support via pasting/bookmarking a `data:` or `javascript:` construction if you really want. As of now the URL bar is GET only when you enter a URL.
> I'm not sure it makes sense for an HTTP protocol standards to describe how browsers should allow it's input in the URL bar - two very different standards realms. Just as a small remark, HTTP protocol standards do - or have at least - considered URL input so far in a wider, client-side meaning. Some details are left for the clients, e.g. it differs across browsers how certain URL characters are interpreted when ente…
Earlier quoted context omitted.
I'm not sure it makes sense for an HTTP protocol method standard to describe how browsers should allow it's input in the URL bar - two very different standards realms. That said you should be able to trigger any custom HTTP request your browser support via pasting/bookmarking a `data:` or `javascript:` construction if you really want. As of now the URL bar is GET only when you enter a URL.
> I'm not sure it makes sense for an HTTP protocol standards to describe how browsers should allow it's input in the URL bar - two very different standards realms. Just as a small remark, HTTP protocol standards do - or have at least - considered URL input so far in a wider, client-side meaning. Some details are left for the clients, e.g. it differs across browsers how certain URL characters are interpreted when ente…
> 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…
Safe requests (all of which are necessarily also idempotent) are not reliably reproducible; GET of the same resource changes if there are server-state changes induced by other requests between GETs.
So, what you suggest is not failing to follow the spec.
We should just create a revision for RFC 2616 to extend the GET method to allow request bodies. Most HTTP frameworks already support this behaviour anyway.
RFC 2616 has already been obsoleted, and there is a draft (I think on its 19th draft or more) RFC obsoleting the set that obsoleted RFC 2616.
> to extend the GET method to allow request bodies.
Adding a new method is safer than changing the semantics of an existing one, “has a body” is a pretty major distinction for an HTTP message, whether a request method or response status.
Earlier quoted context omitted.
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 ..."
> 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.