- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 27 Jan 2012 09:18:09 -0800
- To: "Marat Tanalin | tanalin.com" <mtanalin@yandex.ru>
- Cc: public-html@w3.org
2012/1/27 Marat Tanalin | tanalin.com <mtanalin@yandex.ru>: > 27.01.2012, 21:00, "Tab Atkins Jr." <jackalmage@gmail.com>: >> If you can get the same page back with a GET request, then it >> shouldn't have been a POST in the first place. That's an abuse of >> request semantics, usually just so the page maintains a "pretty URL". > > Since my point is likely misunderstood, let's consider an example for additional clarity. > > We have a no-so-advanced CMS that technically _can't_ make server-side redirects. > > A site based on this CMS has a page that contains a form to add messages, and list of messages added earlier. The form's @action attribute contains same URL as the page that contains the form itself. Since each POST request from the form adds new message, the form _must_ be sent via POST request, not GET request -- it's well-known best-practice approach that GET request should not modify or add something to database (except, well, for visit counters). > > So POST here cannot be replaced with GET at all. If your CMS is dumb enough that it can't do redirects directly, it can always serve the page with a <meta http-equiv="refresh" content="0; url=http://example.com/">. This kinda sucks, but the CMS apparently kinda sucks anyway, so it seems fitting. (I'm quite confused, though - what CMS *can* add things to a server-side database, but *can't* issue a redirect? This is trivial to do in every server-side language I know of.) ~TJ
Received on Friday, 27 January 2012 17:19:00 UTC