51–60 of 131 posts
Earlier quoted context omitted.
> One advantage of GET is I can just copy the URL and share it. no, you cant. if the server requires any headers such as Authorization or Cookie, this method will fail.
They are obviously talking about public urls.
Earlier quoted context omitted.
Funny you should say that: https://httpwg.org/http-extensions/draft-ietf-httpbis-safe-m...
I understand the benefits of QUERY over GET because GET is expected to return a resource in the response. Why not just use POST though? Send a post message to a server asking to conduct a search and sending the results of that query in the response?
"POST" has come to imply a "write" operation, and mixing up the the reads and writes of a system leads to cognitive dissonance.
Earlier quoted context omitted.
verbs don't identify a resource, so why would they be in a URI? A separate format to serialize a request spec is a good idea, sure, but it is a distinctly different thing than the URI of the resource referenced by the request.
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…
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 carry out. "GET /foo" is entirely distinct from "POST /foo", and there are lots of considerations why it has been implemented like that. I cannot recommend reading the spec (or letting ChatGPT summarise it for you) enough, it will really make more sense.
Having said all that, I know what situations you are referring to - say, issuing a PATCH request with an HTML form, or circumventing some redirect bug with a POST request. Still, all of those problems hint at some other, more general issue, and solving such inconvenience would come at the price of a completely broken HTTP specification. Protocols like email, or HTTP, have only been around for so long because they were designed elegantly and carefully. Let's not break that for convenience' sake :)
Or just use GET since it already works. I don't see any problems with large query params. You can also split the search into a POST request and a GET request for the result.
A situational issue that I've run into a number of times with GET is various middle boxes inadvertently logging sensitive data that was in the query string of a GET. By sensitive data, I mean PII and CU information. While we have used POST to side step the issue, it'd be nice if there was a more appropriate method.
Overall, I'm not necessarily inherently against new HTTP methods. If equipment that is supposed to be transparent to HTTP isn't, should be solved elsewhere, not by a new HTTP method.
Wouldn’t be enough to “extend” GET so that it supports a body payload as well?
It already does.
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…
We already have a format to identify an entire request including verb and headers. It’s called HTTP.
HTTP is a two-way messaging protocol. What's being talked about here is the capabilities in hyperlinks. Totally different.
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.
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…
None of this suggestion is about incorporating all of HTTP's functionality. It's just the situations that you say you know I'm referring to -- verbs, things like authorization headers, a POST payload.
Expanding the functionality of hyperlinks wouldn't break anything about HTTP. It would just allow more requests to be defined in a single line of text (a hyperlink), rather than requiring lines of JavaScript to define. The browser (or cURL or whatnot) would convert the link to the actual HTTP request. Zero changes to HTTP.