XMLhttp request problem

Discussion in 'Javascript' started by sudhaoncyberworld@gmail.com, Oct 12, 2005.

  1. Guest

    Hi all

    i am using asp.net v2.0

    In one of my page i am calling another page using xml http , this is
    working fine but first time only ,

    I am sending the request on click of button , when i click the button
    second time, it's returning the previous response and it's not even
    calling that page again, where could be the problem.

    client side (aspx page 1- javascript)

    var http=new ActiveXObject("Msxml2.XMLHTTP");
    http.open("GET","Gensparql.aspx",false);
    http.send();
    if(http.readyState == 4)
    {
    if(http.responseText!=null && http.responseText!='' )
    {
    //my process
    }
    }

    server side (aspx page 2)

    Response.Clear();
    Response.ContentType = "text/xml";
    Response.Write(retVal);
    Response.End();

    //second time returning same previous output and not calling the aspx
    page 2
    Hope u understand my problem,i am in urgent, Thanks in advance
     
    , Oct 12, 2005
    #1
    1. Advertising

  2. knocte Guest

    escribió:
    > Hi all
    >
    > i am using asp.net v2.0
    >
    > In one of my page i am calling another page using xml http , this is
    > working fine but first time only ,
    >
    > I am sending the request on click of button , when i click the button
    > second time, it's returning the previous response and it's not even
    > calling that page again, where could be the problem.
    >
    > client side (aspx page 1- javascript)
    >
    > var http=new ActiveXObject("Msxml2.XMLHTTP");
    > http.open("GET","Gensparql.aspx",false);
    > http.send();
    > if(http.readyState == 4)
    > {
    > if(http.responseText!=null && http.responseText!='' )
    > {
    > //my process
    > }
    > }
    >
    > server side (aspx page 2)
    >
    > Response.Clear();
    > Response.ContentType = "text/xml";
    > Response.Write(retVal);
    > Response.End();
    >
    > //second time returning same previous output and not calling the aspx
    > page 2
    > Hope u understand my problem,i am in urgent, Thanks in advance
    >



    Perhaps you must send HTTP headers informing about how cacheable is the
    content. You could write it so as to expire immediately. BTW, don't use
    only ActiveX, or else other (standards compliant) browsers won't work
    with your page.

    Andrew [ knocte ]

    --
     
    knocte, Oct 12, 2005
    #2
    1. Advertising

  3. Jambalaya Guest

    Append a random number after the url that's being called. The browser
    will not use the cache. Just make sure to use a different random number
    for each call.

    http.open("GET","Gensparql.aspx?nocache=468732156795431",false);
     
    Jambalaya, Oct 12, 2005
    #3
  4. Randy Webb Guest

    Jambalaya said the following on 10/12/2005 10:25 AM:
    > Append a random number after the url that's being called.


    And what is that for?

    > The browser will not use the cache.


    It will if I tell it to.

    > Just make sure to use a different random number for each call.


    Each call of what?

    >
    > http.open("GET","Gensparql.aspx?nocache=468732156795431",false);
    >


    Oh wait, I see now. If you had bothered to quote what you were replying
    to it would be easier to see that your approach has a simple flaw in it.
    Instead of just trying to guess at a random number, you append the
    current time in milliseconds.

    --
    Randy
    comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
    Answer:It destroys the order of the conversation
    Question: Why?
    Answer: Top-Posting.
    Question: Whats the most annoying thing on Usenet?
     
    Randy Webb, Oct 13, 2005
    #4
  5. Jambalaya Guest

    >Oh wait, I see now. If you had bothered to quote what you were replying
    >to it would be easier to see that your approach has a simple flaw in it.
    >Instead of just trying to guess at a random number, you append the
    >current time in milliseconds.


    There was no flaw. Just a different method to accomplish the goal.

    --
    Jambalaya
    Question: What's the #2 most annoying thing on Usenet?
    Answer: Netiquette Nazis.
     
    Jambalaya, Oct 13, 2005
    #5
  6. Randy Webb Guest

    Jambalaya said the following on 10/13/2005 12:22 AM:

    >>Oh wait, I see now. If you had bothered to quote what you were replying
    >>to it would be easier to see that your approach has a simple flaw in it.
    >>Instead of just trying to guess at a random number, you append the
    >>current time in milliseconds.

    >
    >
    > There was no flaw. Just a different method to accomplish the goal.


    And what method is that? Since you did not elaborate and your code was
    hard-coded and showed no signs of being generated, it indicated that one
    should hard-code that random number. That is a flaw in the approach -
    not a different method to accomplish the same goal.

    --
    Randy
    comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
    Answer:It destroys the order of the conversation
    Question: Why?
    Answer: Top-Posting.
    Question: Whats the most annoying thing on Usenet?
     
    Randy Webb, Oct 13, 2005
    #6
  7. Jambalaya Guest

    >>>Oh wait, I see now. If you had bothered to quote what you were replying
    >>>to it would be easier to see that your approach has a simple flaw in it.
    >>>Instead of just trying to guess at a random number, you append the
    >>>current time in milliseconds.


    >> There was no flaw. Just a different method to accomplish the goal.


    >And what method is that?


    You really do seem smarter than this, Randy. I was showing the end
    result of the concatenation so that the original poster would
    understand the concept. I wasn't writing the code for him. I assume
    since he is using xmlhttp that he has sufficient javascript knowledge
    to be able to generate a random number and append it to a string.

    >Since you did not elaborate and your code was
    >hard-coded and showed no signs of being generated, it indicated that one
    >should hard-code that random number.


    No, if you will reread my first post, it indicates the opposite. I
    quote myself, "Just make sure to use a different random number for each
    call."

    >That is a flaw in the approach -
    >not a different method to accomplish the same goal.


    I guess I'll admit there was a flaw. And that is that I didn't write
    all the javascript for the original poster. I guess I'm more of a
    teach-a-man-to-fish sort of guy versus a give-a-man-a-fish guy.

    J
     
    Jambalaya, Oct 13, 2005
    #7
  8. 1.You must generate XML-content on php or ASP and set th header with
    following info: "Content-type: application/xml; Cache-control:
    no-cache;". If you use "clear" XML, the content will be cached.
    2. Code in javascript will be follow:

    var http;
    if (window.XMLHttpRequest) {
    try {http = new XMLHttpRequest();}
    catch(e){http = false;}
    } else if (window.ActiveXObject("Microsoft.XMLHTTP")) {
    try {http = new window.ActiveXObject("Microsoft.XMLHTTP");}
    catch(e) {
    try {http = new window.ActiveXObject("Msxml2.XMLHTTP");}
    catch(e){http = false;}
    } else {
    http = false;
    }
    http.open("GET","Gensparql.aspx",true);
    http.onreadystatechange = function() {
    if (http.readyState == 4)
    if (http.status == 200) {
    //my process
    }
    }
    http.send(null);
     
    Andrew Stephanoff, Oct 13, 2005
    #8
  9. Randy Webb Guest

    Jambalaya said the following on 10/13/2005 4:30 AM:

    >>>>Oh wait, I see now. If you had bothered to quote what you were replying
    >>>>to it would be easier to see that your approach has a simple flaw in it.
    >>>>Instead of just trying to guess at a random number, you append the
    >>>>current time in milliseconds.

    >
    >
    >>>There was no flaw. Just a different method to accomplish the goal.

    >
    >
    >>And what method is that?

    >
    >
    > You really do seem smarter than this, Randy. I was showing the end
    > result of the concatenation so that the original poster would
    > understand the concept. I wasn't writing the code for him. I assume
    > since he is using xmlhttp that he has sufficient javascript knowledge
    > to be able to generate a random number and append it to a string.


    Now it makes sense :)

    >
    >>Since you did not elaborate and your code was
    >>hard-coded and showed no signs of being generated, it indicated that one
    >>should hard-code that random number.

    >
    >
    > No, if you will reread my first post, it indicates the opposite. I
    > quote myself, "Just make sure to use a different random number for each
    > call."


    Fair enough.

    >
    >>That is a flaw in the approach -
    >>not a different method to accomplish the same goal.

    >
    >
    > I guess I'll admit there was a flaw. And that is that I didn't write
    > all the javascript for the original poster. I guess I'm more of a
    > teach-a-man-to-fish sort of guy versus a give-a-man-a-fish guy.


    That's probably why I didn't write the script either, huh? <g>

    --
    Randy
    comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
     
    Randy Webb, Oct 13, 2005
    #9
  10. Jambalaya wrote:
    <snip>
    >>... , it indicated that
    >>one should hard-code that random number.

    >
    > No, if you will reread my first post, it indicates the
    > opposite. I quote myself, "Just make sure to use a
    > different random number for each call."


    It is considerably easier to say "just make sure to use a different
    random number for each call" (assuming "call" is acceptable terminology
    here (which it probably isn't)) than to actually do it. Remember that
    you would have to be keeping track of which random numbers had been
    used, even between sessions, as it would not be too good if the browser
    decided to deliver content that it had downloaded in a previous session
    from its cache in response to a request in a later one.

    That is why using the millisecond time in this context has been
    proposed, as each time will be unique (at least so long as no two times
    are requested within about 60 milliseconds, at most) and it is in the
    nature of time that is does not repeat itself. That is; what is wanted
    is a unique number rather than a random one, and each item in a sequence
    of increasing integer values is unique within that sequnce.

    >>That is a flaw in the approach -
    >>not a different method to accomplish the same goal.

    >
    > I guess I'll admit there was a flaw.


    Yes it is. At lest in part because the proposal that the OP should "make
    sure" that no two random numbers be the same is considerably more
    troublesome than an available alternative.

    > And that is that I didn't write
    > all the javascript for the original poster.
    > I guess I'm more of a teach-a-man-to-fish sort
    > of guy versus a give-a-man-a-fish guy.


    "Fishing" in an HTTP context would be better mastered with an
    understanding of HTTP, and specifically the way in which various HTTP
    headers can be configured to discourage client-side caching of various
    resources (and possibly the different ways in which POST and GET
    requests are handled with regard to caching). With the correct header
    configuration it is possible that the URL hack would be unnecessary,
    else you would see such "random numbers" on the end of every URL on
    every dynamic site.

    Richard.
     
    Richard Cornford, Oct 13, 2005
    #10
  11. Jambalaya Guest

    Richard Cornford wrote:
    <snip>
    > It is considerably easier to say "just make sure to use a different
    > random number for each call" (assuming "call" is acceptable terminology
    > here (which it probably isn't)) than to actually do it. Remember that
    > you would have to be keeping track of which random numbers had been
    > used, even between sessions, as it would not be too good if the browser
    > decided to deliver content that it had downloaded in a previous session
    > from its cache in response to a request in a later one.


    Agreed. However, the odds that the same random number would be
    generated within the lifespan of the cache is sufficiently miniscule to
    preclude the need to keep track of the used numbers. (Especially
    considering the example I used provided for up to 1 quadrillion
    numbers.)

    > That is why using the millisecond time in this context has been
    > proposed, as each time will be unique (at least so long as no two times
    > are requested within about 60 milliseconds, at most) and it is in the
    > nature of time that is does not repeat itself. That is; what is wanted
    > is a unique number rather than a random one, and each item in a sequence
    > of increasing integer values is unique within that sequnce.


    It cannot be guaranteed that each time will be unique. JavaScript uses
    the system clock. Granted, the odds that a user will change the time
    and a second request goes out with the same millisecond timestamp is
    very small. Perhaps 1 in a trillion? ;)

    > >>That is a flaw in the approach -
    > >>not a different method to accomplish the same goal.

    > >
    > > I guess I'll admit there was a flaw.

    >
    > Yes it is. At lest in part because the proposal that the OP should "make
    > sure" that no two random numbers be the same is considerably more
    > troublesome than an available alternative.


    I agree that it would be. But, again, the odds are remote enough to
    preclude the need to do so.

    >
    > > And that is that I didn't write
    > > all the javascript for the original poster.
    > > I guess I'm more of a teach-a-man-to-fish sort
    > > of guy versus a give-a-man-a-fish guy.

    >
    > "Fishing" in an HTTP context would be better mastered with an
    > understanding of HTTP, and specifically the way in which various HTTP
    > headers can be configured to discourage client-side caching of various
    > resources (and possibly the different ways in which POST and GET
    > requests are handled with regard to caching). With the correct header
    > configuration it is possible that the URL hack would be unnecessary,
    > else you would see such "random numbers" on the end of every URL on
    > every dynamic site.


    We agree again! But as this is a JavaScript Usenet group, the
    workaround(hack) suggested involved JavaScript. But just so you know
    that I'm not being stubbornly argumentative, I'll agree that the
    millisecond method is superior assuming no user clock adjustments. The
    random number method would be superior for requests made within 50
    milliseconds of each other.

    Now that I think about it, both methods should be used simultaneously.
    Append the random number after the millisecond timestamp and then you
    have a workaround that avoids the simultaneous request problem and the
    user clock adjustment problem. Genious!
     
    Jambalaya, Oct 13, 2005
    #11
  12. JRS: In article <dim3m7$a4p$1$>, dated
    Thu, 13 Oct 2005 17:57:42, seen in news:comp.lang.javascript,
    Richard Cornford <> posted :
    >
    >That is why using the millisecond time in this context has been
    >proposed, as each time will be unique (at least so long as no two times
    >are requested within about 60 milliseconds, at most) and it is in the
    >nature of time that is does not repeat itself.


    For the present purpose, that, if correctly interpreted, will
    do.

    However, the current time has to be in a form not affected by
    Summer Time (a civil hour in Autumn is repeated, in many
    places); and, for travellers, by change in location : so UTC
    should be used, and +new Date() will give that.

    Also, any system in which a drifty clock is corrected by
    reference to a time source is liable to have repeated times.

    Real Greenwich Mean Time and Real UTC are monotonic, increasing
    by close to / exactly one second per second; buy, when it really
    matters, one should allow for a computer's estimate of time to
    be non-monotonic.

    --
    © John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
    Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
    PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
    Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.
     
    Dr John Stockton, Oct 14, 2005
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    0
    Views:
    508
  2. SudhaGSD

    XMLhttp request problem

    SudhaGSD, Oct 12, 2005, in forum: ASP .Net Web Controls
    Replies:
    1
    Views:
    101
    Milsnips
    Oct 14, 2005
  3. Robert Cholewa

    Problem with XMLHTTP request. Please help! (long)

    Robert Cholewa, Nov 23, 2004, in forum: Javascript
    Replies:
    1
    Views:
    125
    Bradley Baumann
    Dec 19, 2004
  4. Mark

    Javascript XMLhttp request help

    Mark, Jan 27, 2005, in forum: Javascript
    Replies:
    3
    Views:
    124
    Martin Honnen
    Jan 28, 2005
  5. yawnmoth

    Msxml*.XMLHTTP vs. Microsoft.XMLHTTP

    yawnmoth, Nov 7, 2006, in forum: Javascript
    Replies:
    11
    Views:
    392
    Matt Kruse
    Nov 9, 2006
Loading...

Share This Page