As for TempData size and session data size, they are the same, because TempData is session. I would not suggest using session in lieu of TempData, though, because, as I said, TempData already uses session, and using TempData makes your intentions clear.

RedirectToAction("MyAction", new MyValues() { ErrorType = 1, Test = true });

This will put the values in the URL. For small amounts of data, this solves the problem without a race condition.

If you’re really, really concerned about the race condition and want to store more data, or don’t want sensitive server-side only data passed via URL, you could do something like this:

Guid guid = Guid.NewGuid();
Session[guid.ToString()] = myData;
RedirectToAction("MyAction", new MyValues() { g=guid.ToString() });

And then in your view, check the session for a value named with the Guid passed as the "g" parameter in the URL.

As soon as the view starts rendering you could grab the session data, pull it into the view and clear out the session.

If it cannot find that guid then they have either visited the same guid URL twice, or their session has expired.

Like Craig points out, the latter shouldn’t be a problem because if you only use this technique on redirects then your session is not going to timeout.

If the guid is not found, fall back to the default implementation of the view.

However, if you find yourself ever needing to use this situation then you’re probably doing something more deep rooted wrong. Have a think about your whole process - this should be a last resort tool in an obscure situation. Most problems can be resolved in a much purer fashion!

I haven’t considered side issues like session data maximum size, but then temp data maximum size was never discussed, and to be honest I don’t know the details!

Awaiting Hole Picking

Wait a second, George; you’re misquoting me.

Nowhere did I claim that "close to impossible" is a way of dealing with reliability issues. Rather, I said that (1) the intended purpose of TempData is for redirects (I have since confirmed this with a member of the MVC team directly), and (2) it’s close to impossible to mess up TempData when doing a redirect, in non-pathological situations. The link you gave, and, in particular, the two comments from members of the MVC team at that link, support this conclusion.

Yes, it is hypothetically possible to mess this up. Hence, using it for something more critical than the display of an error message would be a mistake. But I haven’t suggested that. Certainly, if someone had suggested passing credit card information, etc., this way, I would disagree with that. But that’s a strawman here.

There is not a choice here between a "reliable" method and an "unreliable" method. We should not pretend that there is some "reliable" method of passing data across a redirect. You could put the data in the Session, but I would argue that the application is more likely to get it wrong this way than with TempData, which is built for the sole purpose. In other words, TempData is probably not perfect, but it is probably a better choice than the alternatives.

Here is the detailed analysis of the race condition:

http://stackoverflow.com/questions/235665/is-there-a-possible-race-condition-when-using-asp-net-mvc-tempdata-across-a-redir

The docs about form data refer to a POST/redirect/GET scenario, which counts as "across requests" to me.