171–180 of 189 posts
Earlier quoted context omitted.
Unlike POST, however, the method is explicitly safe and idempotent, allowing functions like caching and automatic retries to operate.
Putting something in a spec does not automatically make it true. In the real world if you repeat expensive queries more than an undefined amount you get blocked or at least bot-checked.
Having a standard way to do pagination would be extremely useful. If we could add an items (or similar) range header type that would be excellent!
For example, in the HEAD response (and the QUERY response):
accept-ranges: items
items-length: 342
Range: items=0-9Earlier quoted context omitted.
Unlike POST, however, the method is explicitly safe and idempotent, allowing functions like caching and automatic retries to operate.
Putting something in a spec does not automatically make it true. In the real world if you repeat expensive queries more than an undefined amount you get blocked or at least bot-checked.
Terrible news for computing.
Just curious, was it Google/Facebook that sponsored this?
Two of the authors are from Akamai and Cloudflare.
Earlier quoted context omitted.
Not freely. It is idempotent, not safe. So it still can have serious load consequences.
Unlike POST, however, the method is explicitly safe and idempotent, allowing functions like caching and automatic retries to operate.
I wonder if HTML forms will add support for QUERY: This would avoid the annoying re-submission warnings you're getting if you refresh a page that was returned by a POST form submission, since QUERY is required to be idempotent.
If new method support is added, PUT should be used in this scenario.
> https://www.rfc-editor.org/info/rfc10008/#section-2.8 Having a standard way to do pagination would be extremely useful. If we could add an items (or similar) range header type that would be excellent! For example, in the HEAD response (and the QUERY response): accept-ranges: items items-length: 342 In the QUERY request: Range: items=0-9