My situation is that I have a POST cgi script that generates and returns a media file (mp3). One of the clients of this script wants to use an iOS media player (MPMoviePlayer) object that only takes NSURL (basically the URL string) as input. The problem is that on iOS the POST parameters will not be able to be sent using just an NSURL.
 iOS can of course do post requests using other objects (NSURLRequest), but the script takes a while to run, so it is not acceptable to run the request, saving the file to disk, and then pass the file to the media player ojbect. 

At first I thought maybe we should change to GET, and although it wouldn't be good RESTful design, it wouldn't be so bad as long as I set up a robots.txt. But I found a similar question on SO with opinions unequivocally being that GET is a bad idea if you are changing server state with a cgi script, even if it would make access easier:

[Using GET instead of POST to delete data behind authenticated pages](https://stackoverflow.com/questions/2427247/using-get-instead-of-post-to-delete-data-behind-authenticated-pages)

I don't see an easy way out of this short of rewriting a media player object.
Can anyone suggest an alternative to changing the script to GET while still using the url based player?

The scariest thing about using GET is not security/malicious hackers because most of these issues affect POST as well. I'm mainly worried about new 'fixes' in search engine robots/etc that ignore robots.txt. Is there anything else?

Also if there is a justification why GET might be acceptable here I would be interested in that answer as well. I was wondering if the search engine/bot issue is a non issue here because we won't have an http form that submits a GET request anywhere (since the iOS app will do it from within the app), and cgi scripts do not define the request method they are used with (although they can detect this and abort.)