Take the 2-minute tour ×

This might be an odd question, but I have form in MVC3 that posts through json to a controller that is doing a lot of work behind the scenes. While all this is going on, I was hoping to have some messages returned to the user updating them on the current status. "contacting server, submitting request" etc.

It seems that while I can say "return Json(new ...);" to the page, I don't want to return anything until the whole operation is complete. So how could I return strings from the controller to the page before the final return being called? Is this just a silly thing to be doing in the first place?

share|improve this question

4 Answers 4

up vote 2 down vote accepted

it's possible, but i don't think i would do something like that =)

in your action method, if the request is not a AjaxRequest, render a dummy view with the status message you set in ViewData (set the form data in ViewData too); on that view, send a ajaxRequest to the same url (post the form data if needed) and append the response to the page. If the request is AjaxRequest (check in action method), render the true view with the data.

in some cases, you can use some comet technique with real long requests (some large reports in example)

share|improve this answer
mmm, that's an interesting technique and sounds like it could work. The webserver is going to bog down if I start sending too many of these requests, but I think for the few messages I'll be returning this should be fine. Cheers! –  boolean Apr 24 '11 at 16:55


What you want is generally called a "wait page". I've just searched SOF for "json "wait page"" and, suprisingly, didn't find anything. The general approach is your controler intercepts the http-request for "the potententially slow-to-produce page", and immediately returns "the wait page" to the user-agent. A typical "wait page" doesn't give you any "real" feedback on the progress of your request; I guess because doing so would involve a lot of fundamentally unproductive "round trips" (requests) from client-to-server. In fact, my normal wait page is just a "Processing... Please wait..." message above an animated GIF of a "rotating cog". You WaitPage contains a piece of java-script containing with a timer, which periodically sends an "are we there yet" request to the server. If the request is complete the controler (obviously) forwards the initial request to the results page; and if not the controler does nothing, awaiting the next timered-request from the client.

It's a tricky bit of code, and I realise my reply has NOTHING to do with JSON, or MVC (as such); but that's a general outline of how this has been handled this in the past... and nobody seems to complain (too loudly) about the overall effect.

Cheers. Keith.

share|improve this answer

This violates the layered architecture approach. Instead you should use ajax and timers on your web page and query the controller for updates. You controller can use a message buffer in which it stores the updates.

Then you can write a separate controller which returns the messages in the message buffer for each query that the page sends while your main operation is in progress.

share|improve this answer

Have you considered websockets or SignalR? Last time I looked SignalR didn't work across a web farm, but it enables a bidirectional conversation and the server to arbitrarily push to the client when appropriate.

share|improve this answer

Your Answer


