web-API: POSTs and GETs should be to distinct URLs #1485

Open
opened 2011-08-16 23:52:00 +00:00 by davidsarah · 0 comments
davidsarah commented 2011-08-16 23:52:00 +00:00
Owner

When a web browser displays a page that is the result of an HTTP POST request, the URL that it displays in the address bar is the target of the POST, without any query parameters.

If the user cuts-and-pastes or otherwise transfers that URL as a string, then the recipient will probably try to do a GET request on it. If it is also valid for GET requests but fetches something different from the result of the POST, then the user's expectations (based on a perfectly reasonable intuitive understanding of the REST architecture) may be violated.

The Tahoe-LAFS web-API does define POST and GET requests that are valid for the same URL (for example, the POST done by the 'Check' form on an Info page is sent to the same URL as a GET request for the file contents). To avoid the above problem, we should start using a different URL for POST requests, which returns an error for GETs. Note that this can be done without breaking compatibility, since we don't actually have to stop accepting POSTs at the old URLs (it's sufficient that they aren't used by the WUI, so that users will never try to transfer them as strings).

When a web browser displays a page that is the result of an HTTP POST request, the URL that it displays in the address bar is the target of the POST, without any query parameters. If the user cuts-and-pastes or otherwise transfers that URL as a string, then the recipient will probably try to do a GET request on it. If it is also valid for GET requests but fetches something different from the result of the POST, then the user's expectations (based on a perfectly reasonable intuitive understanding of the REST architecture) may be violated. The Tahoe-LAFS web-API does define POST and GET requests that are valid for the same URL (for example, the POST done by the 'Check' form on an Info page is sent to the same URL as a GET request for the file contents). To avoid the above problem, we should start using a different URL for POST requests, which returns an error for GETs. Note that this can be done without breaking compatibility, since we don't actually have to stop accepting POSTs at the old URLs (it's sufficient that they aren't used by the WUI, so that users will never try to transfer them as strings).
tahoe-lafs added the
code-frontend-web
major
defect
1.8.2
labels 2011-08-16 23:52:00 +00:00
tahoe-lafs added this to the undecided milestone 2011-08-16 23:52:00 +00:00
tahoe-lafs modified the milestone from undecided to eventually 2012-03-29 19:44:23 +00:00
Sign in to join this conversation.
No Milestone
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Reference: tahoe-lafs/trac-2024-07-25#1485
No description provided.