That is a SHOULD, not a MUST. In RFCs, SHOULD is a suggestion about what the suggester would like, not a mandate about what you need to do. Plenty of implementations of plenty of RFCs have decided that they don't want to implement a SHOULD item for various good reasons.

A good reason to not want to follow this one is that there is no convenient way to have regular HTML links that log you out (and will work if you have JavaScript off) without using a GET for a non-idempotent operation. You'll note that even gmail does this.

Furthermore it is unreasonable to expect that a large web application developed by a number of people will have no problems. Even if most of the developers have paid attention to this particular recommend (which they won't because most developers have never heard of it, and there are lots of cases where it makes sense to break it), it is unreasonable that you'll be able to quickly QA it for problems left by the remaining developers over a period of years.

Google should know this. I believe that it is their job as good web citizens to not deliberately create lots of problems for lots of people. If they do so and then refuse to stop doing so after widespread damage is proven, I suspect that they'll find that their click-through disclaimer that they are not liable will prove to not be as bulletproof as they might hope.

Furthermore Google has really screwed up if they are letting people see each other's personal information. Reality is that if you have an HTTP login or a cookie that is part of the request, change that and you should get very different results from the same URL.

Cheers,
Ben

They have a non-idempotent logout link in gmail for exactly the reason that I outlined. They also pay attention to login credentials in gmail for exactly the reason that I outlined. The questionable practice is one that they do as well.

You may be holier-than-thou and have never done that, and your employer may have no employees who have done that, but if so then you and your employer are in a definite minority.

Again, if you set out to deliver a product that you know breaks a lot of existing stuff, badly, then you share responsibility for that breakage. It doesn't matter whether you're technically in the right, you're still wrong in my books.

It may be that we'll have to disagree on the merits of Google's actions. But as a practical matter, if they want to fight this, they will lose. They are not more important than the rest of the Internet.

Cheers,
Ben

I agree that there is no evidence that Google is fighting anything yet. But if they persevere in trying to get people to use a product that is this broken, they will.

As for dangerous operations, danger is in the eye of the beholder. For instance suppose that I'm using a site with a logout link from a public computer. First there is the minor annoyance that I can be accidentally logged out by Google. OK, so I log back in, I'm fine. Now I can't logout, though I might think I did because Google shows me the cached page. Now I walk away and am still logged in.

I don't know what you consider dangerous, but I hardly consider this safe.

For a more complex example, consider how difficult this site would be to use if Google was constantly marking forums read for you and you weren't getting uncached versions of the site. Not exactly dangerous, but rather annoying to say the least.

Judging from [link|http://z.iwethey.org/forums/render/content/show?contentid=206328|http://z.iwethey.org...?contentid=206328] you think that admin should be shot for having done that. I beg to differ, and think most people here would as well. Sure, as a result I can try to fool you into clicking on [link|http://z.iwethey.org/forums/actions/forum/markForumRead?forumid=27&markstamp=2005-06-07+09%3a43%3a08-04|this] to get you to exit this conversation. But for most of us the convenience of the interface far outweighs the potential risk.

As for your cross-site red herring, I call BS. First of all with most web toolkits a CGI parameter is a CGI parameter is a CGI parameter. Whether or not people use GET or POST on the front end, on the back end the form will accept and process the parameter. (Assuming that it fits in a GET of course.) Secondly even if you did worry about that fairly arbitrary distinction, it is trivial for other sites to write POST forms which target your script. They can even submit it for you with JavaScript.

In general if you're concerned with providing minimal protection against such nastiness, restricting dangerous operations to POST is a worse than useless first precaution. (It is useless because it doesn't solve the problem. It is worse than useless because you might think that you've done something about it when you haven't.) Instead you should check REFERER. OK, possibly you might restrict GETs in conjunction with locking down what HTML users can submit.

But in any case the point is that historically, potentially dangerous GET urls were not a problem. If someone is using Google's web accelerator, it is.

Cheers,
Ben

PS Disclaimer. I work for [link|http://www.rent.com/|http://www.rent.com/]. If you're a user using Google's web accelerator, user tracking will be all messed up. The result is that your odds of getting your $100 from us are greatly reduced. Even apparently idempotent URLs may be "dangerous"!