I see three problems. The first one is that the Iranians would have to have their own JPEG images to sit in an "uploads" directory on the client, since what you're proposing is a very broad-scale steganography attack. (Or else we'd need a procedural way to generate a great number of images which look indistinguishable from real traffic that you might want to send. In any case we risk that the censors block image uploads and form POSTs.)
Second is, I'm not sure anyone has yet connected steganography with public-key cryptography, but it really does have to be done that way for plausible deniability, otherwise you can just look inside the packets. So, inside the first JPEG linked from index.html there is steganographically hidden a 2048-bit RSA public key, and communication consists of uploading steganographic requests of the form encrypt(public_key, shared_key) | encrypt(shared_key, request). The first segment, the server knows should be 2048 bits = 256 bytes long. My bsencode project (https://github.com/drostie/bsencode) might be useful for formatting the data-to-be-encrypted; you need to transmit something like 32 bytes for a key, 16 bytes for a nonce, 32 bytes of predictable plain text so that the server knows that the request is intentional, perhaps 16 bytes of unrelated randomness just to give the RSA packet some extra entropy, and perhaps we could already specify some aspects of the protocol and intended query in the header as well. The 256 bytes would be plenty to contain an entire handshake.
However, you would have to think long and hard about how the public key is encoded, since it's a two-part data structure and either part -- or the glue -- could "leak" the fact to an adversary able to do basic data-processing that there is an RSA key hiding in plain sight. Also the access pattern might leak this info -- how many places do you know which are important enough that Iranian citizens should have access to them, but follow a predictable pattern of "download HTML, download image, upload image"? The last part is the unique part; uploading images and lots of text is relatively uncommon.
The third problem that I see is the interaction problem: Iran can guess at steganography by its access pattern, lots of large HTTP uploads followed by HTTP downloads -- but it can then confirm the guess by sending its own requests to the same server and validating that it gets valid responses back. So you can target the system by simply trying to use it.
This last problem is much harder, I think. One obvious solution is to only handle one client at a time -- but that is dangerous because it paves the way for denial of service attacks from the government; they just take download of index.html followed by a GET request for a JPEG and try to send their own steganographic request, tying that server up with respect to real traffic.
Mounting a good steganographic attack against the people who run the communications infrastructure is going to be very difficult indeed.