Though this problem was resolved long time back, I was just wondering what the actual problem was.
The problem was resolved just by replacing <a href="javascript:void(0)" onClick="javascript:getNext();">Next </a> with <input type="button" value="Next" onClick="javascript:getNext();"> Using the anchor tag, the HTTPWatch showed that the HTTP operation was aborted by IE, where as by using the button it went on the next page and showed the right set of elements. Can anyone please tell me what the problem was with the anchor tag and why did IE abort the operation. Thanks for all the help! On 2/18/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > Aborted can happen when a proxy is involved, which has been suggested > before as the source of your troubles. I think it would be in your best > interest to purchase HTTPWatch to see the full details, or else find a > free alternative... some options: > > http://www.siliconwold.com/interceptor/interceptor_home.htm > http://www.blunck.info/iehttpheaders.html > > http://www.fileedge.com/Cat/Network-Internet/Browsers-Tools/MMD-HttpHead.html > > None of them seem as good as HTTPWatch, but the price is right :) > > Frank > > zahid mohammed wrote: > > Hi Dave, > > I have used the basic edition of HttpWatch and found these results after > > clicking "next" > > > > Started Time size method Result Type > > 00:01:58.512 0.004 * POST Aborted * > > URL > > > > > http://localhost:8080/WITRApplication/GetOtherSet.do?nextposition=10&rand=93395784 > > 00:02:14.239 0.003 * POST Aborted * > > > http://localhost:8080/WITRApplication/GetOtherSet.do?nextposition=10&rand=53881851 > > > > Since this is a basic edition of HttpWatch I am unable to see the > headers, > > cookies, cache etc. Does anyone know what "Aborted" means in the result > and > > when does it show that? > > > > PLEASE HELP!!! > > Thanks. > > > > On 2/17/06, Dave Newton <[EMAIL PROTECTED]> wrote: > >> zahid mohammed wrote: > >>> If something was fundamentally wrong then why would it work in > >> "FIREFOX". > >> Perhaps because Firefox is less fundamentally broken than IE? > >>> And moreover these two printlns are giving the same result in Firefox > >> but > >>> not in IE i.e after clicking next these are printing the next page's > >> first > >>> element. I am in the process of using HTTPWatch. I'll let u guys know > >> the > >>> result later. > >>> > >> What do you mean by "first element?" Those printlns are half-way > through > >> the source you posted; there is quite a bit of HTML before them. > >> > >> I should rephrase my belief: obviously there is different behavior > under > >> IE, but I'm quite skeptical that it's an issue with caching insofar as > >> the headers you are sending are correct and you are sending a > >> cache-busting unique URL parameter. We use both techniques (and have > for > >> a long time) with zero issues across "all" browsers. > >> > >> I still believe that there is either more going on under IE than you > >> suspect with regards to a proxy, a cache, something, somewhere in the > >> request chain. > >> > >> I would recommend you test w/ a different version of IE6 and see if the > >> problem goes away; if it does then obviously that drop of IE is > >> significantly broken. I would also examine your entire request > >> processing chain, and create a standalone test case without all the > >> extra stuff to make it easier to track down the problem to see if it > >> really _is_ an IE-specific caching bug or if it's somewhere else in the > >> chain. > >> > >> Dave > >> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
