AJAX html won't refresh after data update

Discussion in 'Javascript' started by javelin, Oct 4, 2007.

  1. javelin

    javelin Guest

    I created a feature in a page where a DIV displays child records of
    the current record. From this same page, I can submit the insertion of
    a new child record. However, the while the previous child records
    displayed fine, the newly added ones don't - until I close down IE and
    restart it. I know, there's a setting in IE options which will force a
    refresh on each page load, instead of caching, but I can't access it
    from these computers (NT policy prohibits it, I guess). None of the
    end users can either, so that's not a solution. Anything I can do
    programmatically here?

    Thanks.
    javelin, Oct 4, 2007
    #1
    1. Advertising

  2. javelin

    Robin Guest

    javelin wrote:
    > I created a feature in a page where a DIV displays child records of
    > the current record. From this same page, I can submit the insertion of
    > a new child record. However, the while the previous child records
    > displayed fine, the newly added ones don't - until I close down IE and
    > restart it. I know, there's a setting in IE options which will force a
    > refresh on each page load, instead of caching, but I can't access it
    > from these computers (NT policy prohibits it, I guess). None of the
    > end users can either, so that's not a solution. Anything I can do
    > programmatically here?


    Add a 'unique' variable to the query string of you ajax URI so that
    browser doesn't use the cached copy.

    i.e.
    obj.open('GET','ajax_call.php?recid='+recid+'&z='+
    new Date().getTime(),true);


    HTH
    Robin
    Robin, Oct 4, 2007
    #2
    1. Advertising

  3. javelin wrote:
    > Subject: AJAX html won't refresh after data update


    http://www.mnot.net/cache_docs/


    PointedEars
    --
    Anyone who slaps a 'this page is best viewed with Browser X' label on
    a Web page appears to be yearning for the bad old days, before the Web,
    when you had very little chance of reading a document written on another
    computer, another word processor, or another network. -- Tim Berners-Lee
    Thomas 'PointedEars' Lahn, Oct 4, 2007
    #3
  4. javelin

    Guest

    Dang, Robin! That actually works! Not used to getting such good help
    the first time around :D

    Thanks for the great idea.

    J

    On Oct 4, 9:52 am, Robin <> wrote:
    > javelin wrote:
    > > I created a feature in a page where a DIV displays child records of
    > > the current record. From this same page, I can submit the insertion of
    > > a new child record. However, the while the previous child records
    > > displayed fine, the newly added ones don't - until I close down IE and
    > > restart it. I know, there's a setting in IE options which will force a
    > >refreshon each page load, instead of caching, but I can't access it
    > > from these computers (NT policy prohibits it, I guess). None of the
    > > end users can either, so that's not a solution. Anything I can do
    > > programmatically here?

    >
    > Add a 'unique' variable to the query string of you ajax URI so that
    > browser doesn't use the cached copy.
    >
    > i.e.
    > obj.open('GET','ajax_call.php?recid='+recid+'&z='+
    > new Date().getTime(),true);
    >
    > HTH
    > Robin
    , Oct 5, 2007
    #4
  5. wrote:
    > On Oct 4, 9:52 am, Robin <> wrote:
    >> Add a 'unique' variable to the query string of you ajax URI so that
    >> browser doesn't use the cached copy.
    >>
    >> i.e.
    >> obj.open('GET','ajax_call.php?recid='+recid+'&z='+
    >> new Date().getTime(),true);

    >
    > Dang, Robin! That actually works! Not used to getting such good help
    > the first time around :D
    >
    > Thanks for the great idea.


    That idea is BAD because it fills the browser cache with garbage, and so
    eventually slows down access to other content. Unnecessarily.

    Please don't top-post: http://jibbering.com/faq/


    PointedEars
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
    Thomas 'PointedEars' Lahn, Oct 5, 2007
    #5
  6. javelin

    Guest

    Dang, Robin! That actually works! Not used to getting such good help
    the first time around :D

    Thanks for the great idea.

    J

    On Oct 4, 9:52 am, Robin <> wrote:
    > javelin wrote:
    > > I created a feature in a page where a DIV displays child records of
    > > the current record. From this same page, I can submit the insertion of
    > > a new child record. However, the while the previous child records
    > > displayed fine, the newly added ones don't - until I close down IE and
    > > restart it. I know, there's a setting in IE options which will force a
    > >refreshon each page load, instead of caching, but I can't access it
    > > from these computers (NT policy prohibits it, I guess). None of the
    > > end users can either, so that's not a solution. Anything I can do
    > > programmatically here?

    >
    > Add a 'unique' variable to the query string of you ajax URI so that
    > browser doesn't use the cached copy.
    >
    > i.e.
    > obj.open('GET','ajax_call.php?recid='+recid+'&z='+
    > new Date().getTime(),true);
    >
    > HTH
    > Robin
    , Oct 5, 2007
    #6
  7. Randy Webb wrote:
    > Thomas 'PointedEars' Lahn said the following on 10/5/2007 2:00 PM:
    >> wrote:
    >>> On Oct 4, 9:52 am, Robin <> wrote:
    >>>> Add a 'unique' variable to the query string of you ajax URI so that
    >>>> browser doesn't use the cached copy.
    >>>>
    >>>> i.e.
    >>>> obj.open('GET','ajax_call.php?recid='+recid+'&z='+
    >>>> new Date().getTime(),true);
    >>> Dang, Robin! That actually works! Not used to getting such good help
    >>> the first time around :D
    >>>
    >>> Thanks for the great idea.

    >> That idea is BAD because it fills the browser cache with garbage, and so
    >> eventually slows down access to other content. Unnecessarily.

    >
    > Pure nonsense.


    (sic!)

    It isn't nonsense, it's a fact. (Or have I overlooked your argument by any
    chance?)


    PointedEars
    --
    var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
    ) // Plone, register_function.js:16
    Thomas 'PointedEars' Lahn, Oct 6, 2007
    #7
  8. Thomas 'PointedEars' Lahn a écrit :
    > Randy Webb wrote:
    >> Thomas 'PointedEars' Lahn said the following on 10/5/2007 2:00 PM:
    >>> wrote:
    >>>> On Oct 4, 9:52 am, Robin <> wrote:
    >>>>> Add a 'unique' variable to the query string of you ajax URI so that
    >>>>> browser doesn't use the cached copy.
    >>>> Dang, Robin! That actually works! Not used to getting such good help
    >>>> the first time around :D
    >>>> Thanks for the great idea.
    >>> That idea is BAD because it fills the browser cache with garbage, and so
    >>> eventually slows down access to other content. Unnecessarily.

    >> Pure nonsense.

    > (sic!)
    >
    > It isn't nonsense, it's a fact.


    sic !

    It is well-known among competent Web developers that IE is suffering a
    cache issue with XHR when the call method is "GET". And no headers will
    do anything to it.

    The only solution is to add a dummy unique variable to the querysting.

    *That* is a fact among others !

    --
    laurent
    Laurent vilday, Oct 6, 2007
    #8
  9. Randy Webb wrote:
    > Thomas 'PointedEars' Lahn said the following on 10/5/2007 7:41 PM:
    >> Randy Webb wrote:
    >>> Thomas 'PointedEars' Lahn said the following on 10/5/2007 2:00 PM:
    >>>> wrote:
    >>>>> On Oct 4, 9:52 am, Robin <> wrote:
    >>>>>> Add a 'unique' variable to the query string of you ajax URI so
    >>>>>> that browser doesn't use the cached copy.
    >>>>>>
    >>>>>> i.e. obj.open('GET','ajax_call.php?recid='+recid+'&z='+ new
    >>>>>> Date().getTime(),true);
    >>>>> Dang, Robin! That actually works! Not used to getting such good
    >>>>> help the first time around :D
    >>>>>
    >>>>> Thanks for the great idea.
    >>>> That idea is BAD because it fills the browser cache with garbage,
    >>>> and so eventually slows down access to other content.
    >>>> Unnecessarily.
    >>> Pure nonsense.

    >> (sic!)
    >>
    >> It isn't nonsense, it's a fact. (Or have I overlooked your argument by
    >> any chance?)

    >
    > You have overlooked the argument.


    There was no argument. There was a statement.

    > There is a very good reason for using a query string to force a reload
    > from the server. And no, headers and server settings won't satisfy the
    > need.


    You have not stated the reason; that is no argument, it is a statement.


    PointedEars
    --
    Prototype.js was written by people who don't know javascript for people
    who don't know javascript. People who don't know javascript are not
    the best source of advice on designing systems that use javascript.
    -- Richard Cornford, cljs, <f806at$ail$1$>
    Thomas 'PointedEars' Lahn, Oct 6, 2007
    #9
  10. Laurent vilday wrote:
    > Thomas 'PointedEars' Lahn a écrit :
    >> Randy Webb wrote:
    >>> Thomas 'PointedEars' Lahn said the following on 10/5/2007 2:00 PM:
    >>>> wrote:
    >>>>> On Oct 4, 9:52 am, Robin <> wrote:
    >>>>>> Add a 'unique' variable to the query string of you ajax URI so that
    >>>>>> browser doesn't use the cached copy.
    >>>>> Dang, Robin! That actually works! Not used to getting such good help
    >>>>> the first time around :D
    >>>>> Thanks for the great idea.
    >>>> That idea is BAD because it fills the browser cache with garbage, and so
    >>>> eventually slows down access to other content. Unnecessarily.
    >>> Pure nonsense.

    >> (sic!)
    >>
    >> It isn't nonsense, it's a fact.

    >
    > sic !
    >
    > It is well-known among competent Web developers that IE is suffering a
    > cache issue with XHR when the call method is "GET". And no headers will
    > do anything to it.


    Where is your proof for that?

    > The only solution is to add a dummy unique variable to the querysting.


    Non sequitur.

    > *That* is a fact among others !


    You have to prove that.


    PointedEars
    --
    Prototype.js was written by people who don't know javascript for people
    who don't know javascript. People who don't know javascript are not
    the best source of advice on designing systems that use javascript.
    -- Richard Cornford, cljs, <f806at$ail$1$>
    Thomas 'PointedEars' Lahn, Oct 6, 2007
    #10
  11. Thomas 'PointedEars' Lahn wrote:

    > Laurent vilday wrote:


    >> It is well-known among competent Web developers that IE is suffering a
    >> cache issue with XHR when the call method is "GET". And no headers will
    >> do anything to it.

    >
    > Where is your proof for that?


    The proof for IE is below.

    >> The only solution is to add a dummy unique variable to the querysting.
    >> *That* is a fact among others !

    > You have to prove that.


    http://msdn2.microsoft.com/en-us/library/ms536648.aspx

    | Microsoft Internet Explorer caches the results of HTTP GET
    | requests in the Temporary Internet Files (TIF) folder. In
    | most cases, caching improves performance for data that will
    | not change frequently. To guarantee that the results are not
    | cached, use POST.

    If you want to use 'GET' anyway, use a randomized query-string.

    --
    Bart
    Bart Van der Donck, Oct 6, 2007
    #11
  12. Thomas 'PointedEars' Lahn a écrit :
    > Laurent vilday wrote:
    >> It is well-known among competent Web developers that IE is suffering a
    >> cache issue with XHR when the call method is "GET". And no headers will
    >> do anything to it.

    >
    > Where is your proof for that?


    LOL, and you really pretend to know your stuff ?

    This issue is *VERY* well known, can't you do a few google search to
    know what you talking about ?

    Or better, actually spend more time working with the technology you
    pretend to know instead of babbling about it ?

    You will discover a lot of things. Reality is *far* away from anything
    you keep pretending to know !

    >> The only solution is to add a dummy unique variable to the querysting.

    >
    > Non sequitur.


    <p lang="fr">
    Je comprend pas ta langue gamin, te la joues pas avec ton latin pourri !
    </p>

    >> *That* is a fact among others !

    > You have to prove that.


    LOL, why would I have to proove anything ? Since when did c.l.j. became
    your helpdesk ? I'm not here to educated you ! Do your searches, read
    books (even bad ones), read webpages, experiment, get *LOT* more of real
    experience. Then, come back to us if you have any questions !

    Days after days, you saying a lot of nonsense without prooving much. Why
    would I have to proove anything more to you when I'm right ?

    <FAQENTRY>
    4.45 [IE - XHR - GET] Why is my AJAX page not updated from IE cache when
    using HTTP GET request ?
    Microsoft Internet Explorer caches the results of HTTP GET requests. If
    you need a non cached version of the page, you will have to use a
    randomized query-string or use a HTTP POST request. No headers or server
    configuration will do any help to it.
    <http://msdn2.microsoft.com/en-us/library/ms536648.aspx>
    </FAQENTRY>

    ps : Thomas, I already know my english sucks, no need to correct my
    english grammar errors in this message except the FAQENTRY of course.

    --
    laurent
    Laurent vilday, Oct 6, 2007
    #12
  13. Laurent vilday wrote:
    > <FAQENTRY>
    > 4.45 [IE - XHR - GET] Why is my AJAX page not updated from IE cache when
    > using HTTP GET request ?
    > Microsoft Internet Explorer caches the results of HTTP GET requests. If
    > you need a non cached version of the page, you will have to use a
    > randomized query-string or use a HTTP POST request. No headers or server
    > configuration will do any help to it.


    That is your statement, still lacking proof.

    > <http://msdn2.microsoft.com/en-us/library/ms536648.aspx>


    There is _nothing_ there that says the caching behavior cannot be controlled
    by headers. In fact, it would be very weird behavior if IE's HTTP
    implementation would obey cache control headers in normal operation (and it
    does) and would not when it is triggered through the IXMLHTTPRequest interface.

    > </FAQENTRY>


    PointedEars
    --
    Anyone who slaps a 'this page is best viewed with Browser X' label on
    a Web page appears to be yearning for the bad old days, before the Web,
    when you had very little chance of reading a document written on another
    computer, another word processor, or another network. -- Tim Berners-Lee
    Thomas 'PointedEars' Lahn, Oct 6, 2007
    #13
  14. Randy Webb wrote:
    > Thomas 'PointedEars' Lahn said the following on 10/6/2007 1:18 PM:
    >> Laurent vilday wrote:
    >>> <FAQENTRY>
    >>> 4.45 [IE - XHR - GET] Why is my AJAX page not updated from IE cache when
    >>> using HTTP GET request ?
    >>> Microsoft Internet Explorer caches the results of HTTP GET requests. If
    >>> you need a non cached version of the page, you will have to use a
    >>> randomized query-string or use a HTTP POST request. No headers or server
    >>> configuration will do any help to it.

    >> That is your statement, still lacking proof.

    >
    > When I have tested it extensively, it has proof.


    It has not (logical fallacy: proof by example). Your method of testing may
    be flawed. It starts to become proof the moment a peer review has showed
    that there are no flaws in your method of testing and that the test result
    can be reproduced within the domain of the statement. That would however
    require the above statement to be less general, as not all versions of
    Internet Explorer can be tested against.

    But you already knew that and are simply trolling again.

    > If you want proof, then you are welcome to test it yourself.


    I am not the one who has to prove the above statement.

    You know that, too.

    >>> <http://msdn2.microsoft.com/en-us/library/ms536648.aspx>

    >> There is _nothing_ there that says the caching behavior cannot be controlled
    >> by headers. In fact, it would be very weird behavior if IE's HTTP
    >> implementation would obey cache control headers in normal operation (and it
    >> does) and would not when it is triggered through the IXMLHTTPRequest interface.

    >
    > Perhaps you should follow the rest of the advice in the post you replied
    > to and get out in the real world and find out how things really work
    > instead of trying to defend the way you think things *should* work.


    I am not defending anything. I am saying that not enough proof has
    been presented yet for the statement to be accepted as general truth.

    You know that, too.


    PointedEars
    --
    Anyone who slaps a 'this page is best viewed with Browser X' label on
    a Web page appears to be yearning for the bad old days, before the Web,
    when you had very little chance of reading a document written on another
    computer, another word processor, or another network. -- Tim Berners-Lee
    Thomas 'PointedEars' Lahn, Oct 6, 2007
    #14
  15. FAQEditor wrote:
    > Laurent vilday said the following on 10/6/2007 12:42 PM:
    >> <FA**NTRY>
    >> 4.45 [IE - XHR - GET] Why is my AJAX page not updated from IE cache when
    >> using HTTP GET request ?
    >> Microsoft Internet Explorer caches the results of HTTP GET requests. If
    >> you need a non cached version of the page, you will have to use a
    >> randomized query-string or use a HTTP POST request. No headers or server
    >> configuration will do any help to it.
    >> <http://msdn2.microsoft.com/en-us/library/ms536648.aspx>
    >> </FA**NTRY>

    >
    > <proposed entry>
    > 4.45 Why is my AJAX page not updated properly when using an HTTP GET
    > request in Internet Explorer?
    >
    > Microsoft Internet Explorer caches the results of HTTP GET requests. To
    > ensure that the document is retrieved from the server, you will need to
    > use the POST Method.
    >
    > http://msdn2.microsoft.com/en-us/library/ms536648.aspx
    >
    > </proposed entry>


    Nothing that has not been proven by peer review should be added to the FAQ.
    A statement from the MSDN Library is not sufficient to back up a FAQ entry
    or even a recommendation in the FAQ. There are statements in the MSDN
    Library are biased, insufficient, factually incorrect, or plain nonsense.

    But it figures and tells much of your competence of being the FAQ editor (or
    rather the lack thereof) that you would consider including such a statement
    in the FAQ anyway.


    PointedEars
    --
    Anyone who slaps a 'this page is best viewed with Browser X' label on
    a Web page appears to be yearning for the bad old days, before the Web,
    when you had very little chance of reading a document written on another
    computer, another word processor, or another network. -- Tim Berners-Lee
    Thomas 'PointedEars' Lahn, Oct 6, 2007
    #15
  16. javelin

    Lee Guest

    Thomas 'PointedEars' Lahn said:


    >I am not defending anything. I am saying that not enough proof has
    >been presented yet for the statement to be accepted as general truth.


    Surely you have enough web development experience to know that
    when colleagues warn that some feature doesn't work correctly
    in some browser, that the warning should be considered to be
    at least probably true until you've had a chance to test it.
    You only make yourself look silly by asking them to prove the
    failure to you.


    --
    Lee, Oct 6, 2007
    #16
  17. javelin

    Guest

    On Oct 6, 4:32 am, Randy Webb <> wrote:
    > Thomas 'PointedEars' Lahn said the following on 10/5/2007 7:41 PM:
    > > Randy Webb wrote:
    > >> Thomas 'PointedEars' Lahn said the following on 10/5/2007 2:00 PM:
    > >>> wrote:
    > >>>> On Oct 4, 9:52 am, Robin <> wrote:
    > >>>>> Add a 'unique' variable to the query string of you ajax URI so that
    > >>>>> browser doesn't use the cached copy.
    > >>>>> i.e.
    > >>>>> obj.open('GET','ajax_call.php?recid='+recid+'&z='+
    > >>>>> new Date().getTime(),true);
    > >>>> Dang, Robin! That actually works! Not used to getting such good help
    > >>>> the first time around :D

    >
    > >>>> Thanks for the great idea.
    > >>> That idea is BAD because it fills the browser cache with garbage, and so
    > >>> eventually slows down access to other content. Unnecessarily.
    > >> Pure nonsense.

    >
    > > (sic!)

    >
    > > It isn't nonsense, it's a fact. (Or have I overlooked your argument by any
    > > chance?)

    >
    > You have overlooked the argument. There is a very good reason for using
    > a query string to force a reload from the server. And no, headers and
    > server settings won't satisfy the need.


    I have followed this post with interest as I have experienced some
    strange exceptions to the "IE caches the results of HTTP GET requests"-
    rule. I have not found a concise pattern in my findings yet, but I can
    conclude that IE's internal caching-strategy "agent" is more complex
    than can be listed in a small set of rules. I think that IE has a
    large set of rules (including some state-dependencies) for determining
    whether to fetch data from cache or to do a reload. In my current
    simple test-environment I can reproduce the fact that the "Cache-
    Control" and/or "Expires" headers definately have an effect on whether
    data is fetched from cache or from a reload (in IE, that is).
    Furthermore, IE's caching strategy seems to be dependant on the
    requested document's extension, but I am not completely sure of this
    statement yet. In any case, with my PHP (-extension) scripts, the
    "Cache-Control" and "Expires" headers definately make a difference. On
    the other hand, one could argue that setting the headers will not be a
    good general solution in forcing reloads, because one also has to take
    "forwards compatibility" into account. MS clearly states that the
    "POST" method will "guarantee" a page reload, which simply translates
    into a meaning that they reserve the right to change their GET-
    oriented cache strategy in future versions of IE. I (regret to say
    that I) agree with PointedEars that setting a unique variable to the
    query string is a bad solution for forcing page reloads. But I am also
    saying that I do not know a better alternative solution. If anyone is
    still interested in this subject, just let me know and I will post the
    code I used during testing.
    , Oct 7, 2007
    #17
  18. wrote:
    > On Oct 6, 4:32 am, Randy Webb <> wrote:
    >> Thomas 'PointedEars' Lahn said the following on 10/5/2007 7:41 PM:
    >>> Randy Webb wrote:
    >>>> Thomas 'PointedEars' Lahn said the following on 10/5/2007 2:00 PM:
    >>>>> wrote:
    >>>>>> On Oct 4, 9:52 am, Robin <> wrote:
    >>>>>>> Add a 'unique' variable to the query string of you ajax URI so that
    >>>>>>> browser doesn't use the cached copy.
    >>>>>>> i.e.
    >>>>>>> obj.open('GET','ajax_call.php?recid='+recid+'&z='+
    >>>>>>> new Date().getTime(),true);
    >>>>>> Dang, Robin! That actually works! Not used to getting such good help
    >>>>>> the first time around :D
    >>>>>> Thanks for the great idea.
    >>>>> That idea is BAD because it fills the browser cache with garbage, and so
    >>>>> eventually slows down access to other content. Unnecessarily.
    >>>> Pure nonsense.
    >>> (sic!)
    >>> It isn't nonsense, it's a fact. (Or have I overlooked your argument by any
    >>> chance?)

    >> You have overlooked the argument. There is a very good reason for using
    >> a query string to force a reload from the server. And no, headers and
    >> server settings won't satisfy the need.

    >
    > I have followed this post with interest as I have experienced some
    > strange exceptions to the "IE caches the results of HTTP GET requests"-
    > rule. I have not found a concise pattern in my findings yet, but I can
    > conclude that IE's internal caching-strategy "agent" is more complex
    > than can be listed in a small set of rules. I think that IE has a
    > large set of rules (including some state-dependencies) for determining
    > whether to fetch data from cache or to do a reload. In my current
    > simple test-environment I can reproduce the fact that the "Cache-
    > Control" and/or "Expires" headers definately have an effect on whether
    > data is fetched from cache or from a reload (in IE, that is).


    I don't know about Cache-Control (HTTP/1.1), but Expires (HTTP/1.0) is
    handled at least since IE 4.

    > Furthermore, IE's caching strategy seems to be dependant on the
    > requested document's extension, but I am not completely sure of this
    > statement yet. In any case, with my PHP (-extension) scripts, the
    > "Cache-Control" and "Expires" headers definately make a difference.


    They will also for other resources, but you have to have a Web server that
    supports that and serves the corresponding headers for every such resource.

    > On the other hand, one could argue that setting the headers will not be a
    > good general solution in forcing reloads, because one also has to take
    > "forwards compatibility" into account. MS clearly states that the
    > "POST" method will "guarantee" a page reload, which simply translates
    > into a meaning that they reserve the right to change their GET-
    > oriented cache strategy in future versions of IE.


    Even Microsoft has to obey HTTP or they render their UA not working on the
    Web. It is highly unlikely that they will not implement one of Expires or
    Cache-Control or E-Tag in future versions (provided there will be any).
    Microsoft is especially well-known to be backwards-compatible (no matter
    how misguided that approach is at times).

    The statement in the MSDN Library (which is not a statement from Microsoft
    but a statement of the MSDN Library editor(s)) is one that falls in the
    category "insufficient" or even "factually incorrect" (I have not tested
    `POST' with XHR there yet) that I have named before. As Microsoft has now
    added a Community Content section for each topic, one can only hope that
    further such statements are discovered and documented as being bogus.

    > I (regret to say that I) agree with PointedEars that setting a unique
    > variable to the query string is a bad solution for forcing page reloads.
    > But I am also saying that I do not know a better alternative solution.


    Have you not just confirmed that cache control headers have an effect?
    That is not just random chance.

    > If anyone is still interested in this subject, just let me know and I
    > will post the code I used during testing.


    I'd rather you posted the public URL to your test case(s) as well, so that
    one can observe which response headers are sent and what the result of
    sending them is.


    PointedEars
    --
    var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
    ) // Plone, register_function.js:16
    Thomas 'PointedEars' Lahn, Oct 7, 2007
    #18
  19. javelin

    Guest

    On Oct 7, 2:38 am, Thomas 'PointedEars' Lahn <>
    wrote:
    > wrote:
    > > If anyone is still interested in this subject, just let me know and I
    > > will post the code I used during testing.

    > I'd rather you posted the public URL to your test case(s) as well, so that
    > one can observe which response headers are sent and what the result of
    > sending them is.


    This is something you could have done yourself from the start. Instead
    you seem to have some sort of weird fetish for these troll-like
    discussions.

    Back on-topic:
    A simple method that also seems to do the job (force non-cache re-
    fetch with a GET method) is the following:

    XHRObject.setRequestHeader("If-Modified-Since", "Sat, 1 Jan 2000
    00:00:00 GMT");

    I tested this in IE 7 and it does force a re-fetch. This method might
    be usefull for those who have no control over the server side headers,
    want to use the GET method as opposed to the POST method, and do not
    want to use the unique-variable-in-query-string method.

    Here are some URL's to my very simple test script for testing the
    various GET methods:

    Without any server-side/client-side "ignore cache" headers:
    http://www.samshuijzen.nl/tim/cachetest/index.php
    (IE uses cache)

    With a number of various server side "ignore cache" headers:
    http://www.samshuijzen.nl/tim/cachetest/index.php?withserversideheaders=1
    (IE does a re-fetch each click)

    Without server-side "ignore cache" headers, with "If-Modified-Since"
    request header:
    http://www.samshuijzen.nl/tim/cachetest/index.php?withrequestheader=1
    (IE does a re-fetch each click)

    Tip: Firebug will show the headers sent and returned.

    If anyone encounters a problem with these tests, please let me know.

    Tim Samshuijzen
    , Oct 7, 2007
    #19
  20. wrote:
    > On Oct 7, 2:38 am, Thomas 'PointedEars' Lahn <>
    > wrote:
    >> wrote:
    >>> If anyone is still interested in this subject, just let me know and I
    >>> will post the code I used during testing.

    >> I'd rather you posted the public URL to your test case(s) as well, so that
    >> one can observe which response headers are sent and what the result of
    >> sending them is.

    >
    > This is something you could have done yourself from the start. Instead
    > you seem to have some sort of weird fetish for these troll-like
    > discussions.


    I have no need of testing as I have been using cache controlling HTTP
    headers successfully for several years now. You will observe that we had a
    discussion about this in another context in this very newsgroup about a year
    before; the arguments against those headers and in favor of a changing query
    part were much the same, and no proof whatsoever that they don't work had
    been provided then by the people who made those arguments (which
    unsurprisingly include at least one person who is arguing in much the same
    way now.)

    What you call troll-like discussion I call the reasonable and necessary
    attempt to demand proof for statements that are very unlikely to be true.
    It is up to the people who made those statements/arguments to prove them
    eventually; it is _not_ up to me to prove their statements/arguments wrong.

    Logical fallacy: shifting the burden of proof.


    PointedEars
    --
    var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
    ) // Plone, register_function.js:16
    Thomas 'PointedEars' Lahn, Oct 7, 2007
    #20
    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. Larry Bud

    Formview update--one field won't update

    Larry Bud, Jul 11, 2007, in forum: ASP .Net
    Replies:
    1
    Views:
    388
    Larry Bud
    Jul 11, 2007
  2. Michael Schöller
    Replies:
    1
    Views:
    2,187
    Michael Schöller
    Nov 23, 2009
  3. Replies:
    1
    Views:
    229
  4. Rico
    Replies:
    2
    Views:
    113
  5. Artūras Šlajus

    rubygems won't run on WinXP after system update

    Artūras Šlajus, Jul 6, 2008, in forum: Ruby
    Replies:
    4
    Views:
    86
    Artūras Šlajus
    Jul 7, 2008
Loading...

Share This Page