-
Notifications
You must be signed in to change notification settings - Fork 152
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
QUERY in HTML forms #2228
Comments
Yes, we could ask, but I'm pessimistic. |
@annevk? Seems like it's something that could be polyfilled... |
Could this be explained more, or is there a link to something that would? (In case it’s useful: where |
It would be a further extension to the same-origin policy, especially if we don't require CORS (and if we do want CORS, that will be a pain since this is a navigation and not an ordinary fetch). As such, it would be either risky or not worth the effort. whatwg/html#3577 has some past discussion on this regarding DELETE and PUT methods where I'm mostly beating the same drum. (You also make a good point that navigation and session history make some assumptions around POST being the only other method in existence, but there is an effort underway at getting those concepts better standardized and made interoperable between browsers which would in theory make it easier to make changes there.) |
Thanks, @annevk. Will close this as indicated. |
While I understand the risk involved with adding support for unsafe methods like
Where can I follow or read up on this effort, @annevk? |
It has landed in the HTML Standard so you could read about navigation there. I haven't checked myself yet though if all of form submission got refactored as well. Also, my comment above might seem more hopeful than the reality, which is that changes to form submission will be hard. And almost definitely any new kind of cross-origin method would require some kind of opt-in as the safety we care about is not that of the method definition of safety, but that of end users. |
I wonder if it is worth exploring whether HTML might add QUERY to GET and POST for form submission. It could use application/x-www-wossname and so might be a drop-in replacement for POST in effect, without the unsafe connotations.
I don't know how extensive the GET/POST assumption is, which would be the main reason not to. But maybe we could at least ask. At which point, close this issue; I don't think that any change is needed in the IETF document in response to this.
The text was updated successfully, but these errors were encountered: