71–80 of 131 posts
TIL sending a POST request to a URL invalidates the cache for GET requests of the same URL. Going to have to review my REST APIs to make sure that’s not a problem.
Incredible, I did not know that. Does anybody point out to some resources to learn more about this behavior?
Earlier quoted context omitted.
SEARCH can have a request body. Many systems limit the length of the URL, so this is significant.
So can POST. It's entirely redundant
Earlier quoted context omitted.
> I don't see any problems with large query params. Most servers will reject URLs after a certain size, 4-8KB.
This is correct, and one only needs to consider the impact of large or unlimited length urls on server memory consumption per request to see that a relatively small limit is desirable and even necessary.
The missing ones are HTTP OPEN/CLOSE to improve the sessions management and security audits.
From the very first line in the RFC[1]:
"The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems."
Which is why you need to send a header every time you make a request with authorization data.
Given that: no, stateful methods like OPEN/CLOSE would not fit at all with how HTTP is designed to work.
Alternative naive solution: Add a body to GET requests. As I said, this is totally naive. Is there some obvious reason why this is a terrible idea, or not really possible?
Earlier quoted context omitted.
I'm pretty sure you know what the parent means. Forget about what acronyms stand for. The thing that hyperlinks point to and you can type in your browser bar is called the URL or the link. And the point is that being able to specify a verb and headers in a link would be super useful in certain situations. Continue to call it a URL or URI and just change the "R" in those from Resource to Request, semantics problem sol…
You're ignoring such a huge part of the HTTP specification there, like request idempotency, caching, the security model, and surely stuff I'm forgetting right now. HTTP, at its heart, is a way to compose an action from a verb and a noun - such as "get this", or "update that". The request method, or verb, is intertwined with the URI, or resource, the noun - together, they form the action the user agent intends to carr…
https+rpc:||news.ycombinator.com|reply?id=36096485&goto=item%3Fid%3D36095032%2336096485#method=PUT#H-Accept=text/html
with | instead of / to workaround this site encoding
This seems reasonable, but unlikely to happen. GET is already pretty much sufficient, especially given that clients generally support megabytes worth of query strings in these modern times. If we're doing this though, I'll cast my vote for naming it more semantically as QUERY, and forgoing whatever little WebDAV compatibility would be had otherwise.