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]
