How do I find out what getwork would have returned for an already mined block? Lets say I want to find out what getwork would have returned for an already mined block http://blockexplorer.com/block/00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d. How would I go about doing this?
Since we have quite a few questions about mining I took the liberty of creating a tool that demonstrates how to get from the getwork to the actual hashes and testing them against the target.

Your question is simply the reverse direction of mining, so let's get started.

All parameters are taken from the actual block.
This is a version 1 block so we start with the 01000000 (1 little
endian). This is followed with the 32 byte prev_hash, again in little
endian:

00000000000008a3a41b85b8b29ad444def299fee21793cd8b9e567eab02cd81


becomes

81cd02ab7e569e8bcd9317e2fe99f2de44d49ab2b8851ba4a308000000000000


same goes for the merkle root:

2b12fcf1b09288fcaff797d71e950e71ae42b91e8bdb2304758dfcffc2b620e3


becomes

e320b6c2fffc8d750423db8b1eb942ae710e951ed797f7affc8892b0f1fc122b


Next comes the timestamp. 1305998791 (4dd7f5c7 in big endian) is
c7f5d74d in little endian. Then the bits (encoded difficulty)
440711666 is 1a44b9f2 in big endian and f2b9441a in little endian. And
finally the nonce. Since you are asking for the getwork this is the
part that your miner will have to find, hence we just mark it out with
0 (00000000).

Putting it all together we have a data field of the getwork request
that is 

0100000081cd02ab7e569e8bcd9317e2fe99f2de44d49ab2b8851ba4a308000000000000e320b6c2fffc8d750423db8b1eb942ae710e951ed797f7affc8892b0f1fc122bc7f5d74df2b9441a00000000


Then getwork does a strange thing: it chunks the header up into groups
of 4 byte and switches the endianness. So that this string becomes

00000001ab02cd818b9e567ee21793cddef299feb29ad444a41b85b8000008a300000000c2b620e3758dfcff8bdb2304ae42b91e1e950e71aff797d7b09288fc2b12fcf14dd7f5c71a44b9f200000000


This is exactly 80 bytes in length and corresponds to the data field
(without padding). The getwork however includes some padding to become
two SHA-256 blocks of length 64 bytes.

The padding is discarded by the miner, but for completeness:

000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000


Next in the getwork we have the midstate. This is simply first 64
bytes of the header with a partially applied first round of hashing,
hence we can recover it from the block header (or data):

93c524951367c505ba69e616a010282d376ee807daa9562f69ce5bcd2dda787a


The getwork also includes an additional field that keeps some internal
state from the SHA-256 algorithm, the hash1 field:

 00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000


It is always constant, and is pretty useless.

The final field in our reconstruction of the getwork request is the
target. This is the one field we cannot actually reconstruct as it
depends on the pool setting that provided the work. It is likely to be
difficulty 1, hence the field itself is:

00000000FFFF0000000000000000000000000000000000000000000000000000


which is a long, below which the found hash has to be. Due to this
being Bitcoin it is again little endian and becomes

0000000000000000000000000000000000000000000000000000ffff00000000


The entire reconstructed getwork should look something like this

{
  "midstate" : "bfc1dbf82dd6335830eb42a5258fb7ceb4c566ed2ae7ec4ed1d23bd9dbbff68f",
  "data" : "00000001ab02cd818b9e567ee21793cddef299feb29ad444a41b85b8000008a300000000c2b620e3758dfcff8bdb2304ae42b91e1e950e71aff797d7b09288fc2b12fcf14dd7f5c71a44b9f200000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000",
  "hash1" : "00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000",
  "target" : "0000000000000000000000000000000000000000000000000000ffff00000000"
}


To see how a miner finds a block from these parameters just enter them in the manual miner I created. Notice that if we fill in the nonce that is in the block (2504433986 or 9546a142 in its hex representation), we indeed get a block of the required difficulty.

Edit: Frank Buss contacted me for a correction: the midstate I posted above was wrong.