Thanks crenz,
Yeah, I made the same observation when I rejected cookies using lynx. THe thing is, when I view the first search page using yr original hack, I get the first page of results but I also get a message(at the start of the page) saying I have been disconnected from the search.
Also if you do the search in IE6, you will only see the ids being passed via the query string for the first page of search results. For subsequent pages (when you click NEXT) you wont see any mention of ids in the query string. But, for our program, if you include the two ids in the string anyway, you get a message (cant remember exactly) but something about the server being buzy (the server isnt buzy - but what ever loop your fall out of you end up getting this message). If you leave the ids out of the search string(as in my code at the moment), you get a message saying that the searching utility only works for Netscape + IE. For both attempts, you get no results for all attempts to veiw beyond the first page of results - instead you get one of the two afore mentioned error messages. Therefore I'm guessing that the ids need to be passed, but IE is using a different method perhaps - i really dont know at this stage. Maybe when you include the ids the second time, the server thinks its processing the first again (i.e. it uses the existance of the ids in the search string to establish if its the 1st results page or a subsequent one)...and thats why you get two different sets of errors, for subsequent search pages, dispite the fact that I would have expected the server to ignore the ids as the NEXT links dont contain them.
Just now I've tried repeating the search in IE. When the first page of results displayed, I copied the url in the address window and removed the engine and session ids, I then opened up netscape, pasted in the new url and the search worked fine. THerefore I dont think the browsers ever needs to recieve the ids via the the query string. I'm lost, how about you?