Just hit a roadblock with coolrom.com - I can't for the life of me figure out what the hell they are doing to prevent me from fullfilling the request...
The thing is - I think I figured out how they do it:
They use two hidden-fields in the form which will send POST-Data to the server after you click on "Start download". I can see with a sniffer that these POST-Data get transmitted.
So now I figured I just download the page, parse it and get the values from those two hidden fields. That is totally working...
As a result you will get a variable with randomname=randomvalue - exactly like on the original page. The second field is called "sid" which holds your PHP-Session-ID. I set this with the use of my cookie I generated after visiting the page. Now - everything seems to be fine: Matching randomname=randomvalue variable and a matching sid=phpsessid . Oh - of course I also use the cookie to be used.
Now I went ahead and resembled THE COMPLETE HTTP-Header of the request made by my browser. It is literally the same header (with different values for randomname=randomvalue and sid=phpsessid obviously though), with the same User-Agent, Content-Length, etc. - yet the site refuses to deliver the octet-stream and redirects me to the rom-detail-page instead.
I...just don't know how the hell they are doing it. Frustrating.
(@Bstrdsmkr: The problem with coolrom seems to be that they are using the webserver to deliver the contents of the file. You don't directly access the file itself via a direct link but the server delivers a stream which would have to be written to the disk manually. So - after posting the correct URL to the server you get a octet-stream as a response, not a HTML page
)