You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In web applications, handling form submits and links to perform actions can be cumbersome - especially around two issues: rendering feedback messages and refreshing the page.
Imagine a page that contains a todo list. There is a form to capture new items, and links next to existing items to remove those items.
The link to remove items, when clicked, will result in a GET request. The URL must be different to the URL of the page, probably containing query parameters about which item to remove. When the link is clicked, we want the user to be presented with the same todo list page they were viewing, but with the item removed, and a feedback message saying "Item removed". We also want the user to be able to refresh the page, and for that refresh request not to result in a second attempt to remove the item from the list. If a user refreshes the page, there should be no feedback message presented, as refreshing the page did not result in any action being taken. Feedback messages should only be displayed in response to actions being attempted - a "remove item" link being clicked, or a new item submitted via form POST.
When the user clicks the remove item link, on the server, we first attempt to do the action requested (remove the item from the todo list), and then must decide on a response to send to the client.
If we decide to respond by rendering the page, then the feedback message is easy - we already have the result of attempting to process the action in the current request. We can render the page and include the feedback message. However, this leaves the client URL as the URL to the "remove item" action. If the client refreshes the page, it results in a GET request that the server will handle as a second attempt to remove the item.
If we respond by redirecting the client to the URL of the page (not the URL of the "remove item" action), then the refresh problem is solved, but the feedback message becomes a problem. If we encode the feedback message as parameters to the page, then refreshing the page will display the feedback message against our wishes. The alternative is the server must keep some record of the feedback messages on the server, match that information to the next request after the redirect and know to show it only once.
This makes the server side more complicated - we cannot just handle this in a single request, we must use session state, which must be accounted for in load balancing etc.
The issue is very similar with POSTing the form. We don't want refreshing the page we get after POSTing the form to result in a second POSTing of the form data. The POST, redirect, GET pattern is often used, but again, this makes rendering feedback difficult because the server must retain the feedback across multiple request cycles.
We would be able to handle this in a single request if we could tell the client to refresh strictly using a GET request to a specific URL.
Concise use case:
We want to be able to render a page in response to both GET and POST requests that, when refreshed, results in strictly a GET request to potentially different URL than the currently requested URL.
What solutions exist today?
This can be achieved by including Javascript that uses the History API:
So everything is already in place to support this.
I suggest that this should be a standard HTML feature not requiring Javascript. A new link type would be especially useful, as it could be used in HTTP headers.
How would you solve it?
I would add it as a new link type.
<link rel="refresh" href="refresh url here">
Similar to link type canonical in meaning, but should cause the browser to behave as though it had encountered the following:
What problem are you trying to solve?
In web applications, handling form submits and links to perform actions can be cumbersome - especially around two issues: rendering feedback messages and refreshing the page.
Imagine a page that contains a todo list. There is a form to capture new items, and links next to existing items to remove those items.
The link to remove items, when clicked, will result in a GET request. The URL must be different to the URL of the page, probably containing query parameters about which item to remove. When the link is clicked, we want the user to be presented with the same todo list page they were viewing, but with the item removed, and a feedback message saying "Item removed". We also want the user to be able to refresh the page, and for that refresh request not to result in a second attempt to remove the item from the list. If a user refreshes the page, there should be no feedback message presented, as refreshing the page did not result in any action being taken. Feedback messages should only be displayed in response to actions being attempted - a "remove item" link being clicked, or a new item submitted via form POST.
When the user clicks the remove item link, on the server, we first attempt to do the action requested (remove the item from the todo list), and then must decide on a response to send to the client.
If we decide to respond by rendering the page, then the feedback message is easy - we already have the result of attempting to process the action in the current request. We can render the page and include the feedback message. However, this leaves the client URL as the URL to the "remove item" action. If the client refreshes the page, it results in a GET request that the server will handle as a second attempt to remove the item.
If we respond by redirecting the client to the URL of the page (not the URL of the "remove item" action), then the refresh problem is solved, but the feedback message becomes a problem. If we encode the feedback message as parameters to the page, then refreshing the page will display the feedback message against our wishes. The alternative is the server must keep some record of the feedback messages on the server, match that information to the next request after the redirect and know to show it only once.
This makes the server side more complicated - we cannot just handle this in a single request, we must use session state, which must be accounted for in load balancing etc.
The issue is very similar with POSTing the form. We don't want refreshing the page we get after POSTing the form to result in a second POSTing of the form data. The POST, redirect, GET pattern is often used, but again, this makes rendering feedback difficult because the server must retain the feedback across multiple request cycles.
We would be able to handle this in a single request if we could tell the client to refresh strictly using a GET request to a specific URL.
Concise use case:
We want to be able to render a page in response to both GET and POST requests that, when refreshed, results in strictly a GET request to potentially different URL than the currently requested URL.
What solutions exist today?
This can be achieved by including Javascript that uses the History API:
So everything is already in place to support this.
I suggest that this should be a standard HTML feature not requiring Javascript. A new link type would be especially useful, as it could be used in HTTP headers.
How would you solve it?
I would add it as a new link type.
Similar to link type
canonical
in meaning, but should cause the browser to behave as though it had encountered the following:Anything else?
Thanks for all you do.
The text was updated successfully, but these errors were encountered: