Forcing browsers not to use their cache for images

Discussion in 'Javascript' started by Edward Diener, Jan 25, 2008.

  1. I am working on a web application which programatically changes an image
    on the server side ( via ImageMagick ) on the roundtrip between client
    and server. When the web page, in which the img tag resides, is
    redisplayed, I need Firefox to reread the web page in order to redisplay
    the image correctly rather than take the image from its cache.

    I have been told that the only reliable way to do this is by using the
    content header of the web page to specify certain values which,
    according to W3C, browsers are supposed to follow to tell it how to
    treat the cache. I have done this, according to the documentation I have
    found, and yet the browser does not redisplay the image from the URL but
    continues to display it by using its cache. This displays the image
    incorrectly since it has changed on the server in the roundtrip between
    client and server and back again.

    The problem occurs in Firefox ( 2.0.0.11 ) and with IE6 and IE7 also. I
    have not tried to test it with any other browsers since the
    specification for the web application is that it is only guaranteed to
    work with Firefox and IE. The fact that the problem exists with IE as
    well as Firefox suggests that some combination in the content header is
    not correct to force browsers to not use the cache but instead to reread
    the data from the img URL.

    Here is the content header, without the cookies, from such a page, as
    extracted live:

    --------------------------------------------------------

    Content-type: text/plain
    HTTP/1.1 200 OK
    Server: ""
    Date: Thu, 24 Jan 2008 16:01:45 GMT
    Content-type: text/html
    Pragma: no-cache
    Cache-control: no-cache,no-store,must-revalidate

    --------------------------------------------------------

    If anybody can see what is incorrect in the content header and tell me
    what I have to change in order to cause the browser to redisplay the
    image from the URL and not from its cache, it would be highly
    appreciated by me.

    Getting browsers to redisplay the image correctly, from changes made on
    the server side, is crucial to this particular application, and this
    problem has persisted for much of the life of the application without a
    resolution.

    Thank you !
     
    Edward Diener, Jan 25, 2008
    #1
    1. Advertising

  2. Edward Diener wrote:
    > [...]
    > The problem occurs in Firefox ( 2.0.0.11 ) and with IE6 and IE7 also. [...]
    > Here is the content header,


    There is no such thing.

    > without the cookies, from such a page, as extracted live:
    >
    > --------------------------------------------------------
    >
    > Content-type: text/plain

    ^^^^^^^^^^^^^^^^^^^^^^^^
    > HTTP/1.1 200 OK
    > Server: ""

    ^^
    That header is invalid. See RFC 2616, section 14.38:

    http://www.rfc-editor.org/rfc/rfc2616.txt

    > Date: Thu, 24 Jan 2008 16:01:45 GMT
    > Content-type: text/html


    Declaring the encoding of the resource with the `charset' parameter is
    strongly recommended:

    http://www.w3.org/TR/html401/charset.html#h-5.2.2

    That aside, have you not already declared the Content-Type? There can only
    be one Content-Type header per response message, and the status code has to
    come before all headers.

    > Pragma: no-cache
    > Cache-control: no-cache,no-store,must-revalidate


    You have declared the caching policy, but you have not provided any header
    that would allow the user agent to recognize a change in the resource as
    compared to the cached one. The Date header does not suffice (see RFC 2616,
    section 14.18), you have to provide one or more of Content-Length (14.13),
    Content-MD5 (14.15), ETag (14.19), Expires (14.21), or Last-Modified (14.29).

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


    The From header of your NetNews message is invalid too (not to mention
    disregarding Netiquette, see RFC 1036, section 2.1.1 (which refers to RFC
    2822, section 3.4.1), and possibly the Acceptable Use Policy of your Usenet
    access provider. Please fix that.


    HTH

    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, Jan 25, 2008
    #2
    1. Advertising

  3. Thomas 'PointedEars' Lahn wrote:
    > Edward Diener wrote:
    >> [...]
    >> The problem occurs in Firefox ( 2.0.0.11 ) and with IE6 and IE7 also. [...]
    >> Here is the content header,

    >
    > There is no such thing.


    There is no such thing as an HTML page content header ? Please explain.

    >
    >> without the cookies, from such a page, as extracted live:
    >>
    >> --------------------------------------------------------
    >>
    >> Content-type: text/plain

    > ^^^^^^^^^^^^^^^^^^^^^^^^
    >> HTTP/1.1 200 OK
    >> Server: ""

    > ^^
    > That header is invalid. See RFC 2616, section 14.38:


    That is wonderfully cryptic but I am guessing you are telling me that
    the Server must have a value rather than an empty string.

    >
    > http://www.rfc-editor.org/rfc/rfc2616.txt
    >
    >> Date: Thu, 24 Jan 2008 16:01:45 GMT
    >> Content-type: text/html

    >
    > Declaring the encoding of the resource with the `charset' parameter is
    > strongly recommended:
    >
    > http://www.w3.org/TR/html401/charset.html#h-5.2.2


    OK, I hear you !

    >
    > That aside, have you not already declared the Content-Type? There can only
    > be one Content-Type header per response message, and the status code has to
    > come before all headers.


    Was there not a "Content-type: text/html" in the above ? Are you saying
    that the content type is invalid because the status code comes after it
    ? I don't generate a status code, I just set the content header fields
    in my code.

    >
    >> Pragma: no-cache
    >> Cache-control: no-cache,no-store,must-revalidate

    >
    > You have declared the caching policy, but you have not provided any header
    > that would allow the user agent to recognize a change in the resource as
    > compared to the cached one. The Date header does not suffice (see RFC 2616,
    > section 14.18), you have to provide one or more of Content-Length (14.13),
    > Content-MD5 (14.15), ETag (14.19), Expires (14.21), or Last-Modified (14.29).


    If I provide an Expires, what do I set the value to ? Is -1 a valid
    value ? Previously I had an Expires: -1, to force expiration, but that
    did not cause my problem to go away.

    >
    > See also http://www.mnot.net/cache_docs/
    >
    >
    > The From header of your NetNews message is invalid too (not to mention
    > disregarding Netiquette, see RFC 1036, section 2.1.1 (which refers to RFC
    > 2822, section 3.4.1), and possibly the Acceptable Use Policy of your Usenet
    > access provider. Please fix that.


    Sorry but this is way too cryptic for me. I appreciate your knowledge
    but I have no idea what you mean by saying the From header is invalid.
    If you are criticizing my Usenet message to this newsgroup you are just
    being silly and hypercritical to no good end.

    Hopefully restoring the Expires: -1 value and putting in a valid Server
    value will fix my problem but if it does not I will post again.

    Thanks for your help !
     
    Edward Diener, Jan 25, 2008
    #3
  4. Edward Diener wrote:
    > Thomas 'PointedEars' Lahn wrote:
    >> The From header of your NetNews message is invalid too (not to mention
    >> disregarding Netiquette, see RFC 1036, section 2.1.1 (which refers to
    >> RFC 2822, section 3.4.1), and possibly the Acceptable Use Policy of
    >> your Usenet access provider. Please fix that.

    >
    > Sorry but this is way too cryptic for me.


    You could have used your favorite search engine instead of playing stupid.

    > I appreciate your knowledge but I have no idea what you mean by saying
    > the From header is invalid. If you are criticizing my Usenet message to
    > this newsgroup you are just being silly and hypercritical to no good end.
    >

    ,-<http://www.att.net/csbellsouth/s/s.dll?spage=cg/legal/att.htm&leg=aup
    |
    | Spam/E-mail/Usenet Abuse
    |
    | Violation of the CAN-SPAM Act of 2003, or any state or federal law
    | regulating e-mail services, constitutes an automatic violation of this AUP
    | and AT&T reserves the right to seek damages and other available relief
    | against Customer, as applicable.
    |
    | Spam/E-mail/Usenet Abuse is prohibited on AT&T IP Services. Examples of
    | Spam/E-mail/Usenet Abuse include but are not limited to the following
    | activities:
    |
    | [...]
    | # posting a single message, or messages to online forums or newsgroups,
    | that could reasonably be expected to provoke complaints;
    | # posting messages to or canceling or superseding messages on an online
    | forum or newsgroup in a manner that violates the rules of the forum or
    | newsgroup or that contain forged header information.
    | [...]

    You have been warned.


    Score adjusted,

    PointedEars
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
     
    Thomas 'PointedEars' Lahn, Jan 25, 2008
    #4
  5. Edward Diener

    Stevo Guest

    Edward Diener wrote:
    > I have been told that the only reliable way to do this is by using the
    > content header of the web page to specify certain values which,


    I don't think that this is the only way to do it. I think individual
    browser settings override any settings your server might return. You may
    tell the browser to request the file every time, but if the browser is
    set to only check once per session, I believe the browser wins and does
    exactly that.

    You can reload the image again with a random query string. That's a
    pretty standard way of doing things.

    A js function like this would reload the image and break the caching:

    function reloadImage(imgobj,imgpath)
    {
    var rand = Math.floor(Math.random()*10000000);
    imgpath += "?" + rand;
    if(imgobj)
    imgobj.src=imgpath;
    }

    You'd get requests to your server like this:

    myimg.gif?123456
    myimg.gif?7959831234
    etc.
     
    Stevo, Jan 25, 2008
    #5
  6. Thomas 'PointedEars' Lahn wrote:
    > Edward Diener wrote:
    >> Thomas 'PointedEars' Lahn wrote:
    >>> The From header of your NetNews message is invalid too (not to mention
    >>> disregarding Netiquette, see RFC 1036, section 2.1.1 (which refers to
    >>> RFC 2822, section 3.4.1), and possibly the Acceptable Use Policy of
    >>> your Usenet access provider. Please fix that.

    >> Sorry but this is way too cryptic for me.

    >
    > You could have used your favorite search engine instead of playing stupid.


    It is you who are stupid since clear communication seems beyond you, and
    you seem to think that cryptic communication is somehow real "cool"
    rather than just being annoying.

    >
    >> I appreciate your knowledge but I have no idea what you mean by saying
    >> the From header is invalid. If you are criticizing my Usenet message to
    >> this newsgroup you are just being silly and hypercritical to no good end.
    >>

    > ,-<http://www.att.net/csbellsouth/s/s.dll?spage=cg/legal/att.htm&leg=aup
    > |
    > | Spam/E-mail/Usenet Abuse
    > |
    > | Violation of the CAN-SPAM Act of 2003, or any state or federal law
    > | regulating e-mail services, constitutes an automatic violation of this AUP
    > | and AT&T reserves the right to seek damages and other available relief
    > | against Customer, as applicable.
    > |
    > | Spam/E-mail/Usenet Abuse is prohibited on AT&T IP Services. Examples of
    > | Spam/E-mail/Usenet Abuse include but are not limited to the following
    > | activities:
    > |
    > | [...]
    > | # posting a single message, or messages to online forums or newsgroups,
    > | that could reasonably be expected to provoke complaints;
    > | # posting messages to or canceling or superseding messages on an online
    > | forum or newsgroup in a manner that violates the rules of the forum or
    > | newsgroup or that contain forged header information.
    > | [...]
    >
    > You have been warned.


    I am terribly scared that the thought police, led by you, will come and
    take me away.

    >
    >
    > Score adjusted,


    Whatever that means !!!
     
    Edward Diener, Jan 26, 2008
    #6
  7. Stevo wrote:
    > Edward Diener wrote:
    >> I have been told that the only reliable way to do this is by using the
    >> content header of the web page to specify certain values which,

    >
    > I don't think that this is the only way to do it. I think individual
    > browser settings override any settings your server might return. You may
    > tell the browser to request the file every time, but if the browser is
    > set to only check once per session, I believe the browser wins and does
    > exactly that.


    So you are saying that there is essentially no programmatic way of
    forcing browsers to reload an image from its URL rather than taking the
    image from its cache ?

    You may be right but that seems utterly illogical from this programmer's
    point of view. It essentially says that any web application, which
    depends on images being changed on the server side be reflected by the
    browser's display of that image, can not possibly work. This makes web
    application programming utterly hopeless.

    >
    > You can reload the image again with a random query string. That's a
    > pretty standard way of doing things.
    >
    > A js function like this would reload the image and break the caching:
    >
    > function reloadImage(imgobj,imgpath)
    > {
    > var rand = Math.floor(Math.random()*10000000);
    > imgpath += "?" + rand;
    > if(imgobj)
    > imgobj.src=imgpath;
    > }
    >
    > You'd get requests to your server like this:
    >
    > myimg.gif?123456
    > myimg.gif?7959831234
    > etc.


    Already tried and does not work. The browser ignores the request string
    part of the URL and continues to reload the image from its cache.

    I have to believe that there is some simple way of telling the browser,
    for a particular web page, to go out and reload the image from its URL
    rather than assuming it has the most recent version of that image in its
    cache. The fact that it has been impossible to find out from anyone or
    anywhere what that way is still amazes me, as if I were asking for some
    hidden secret which only initiates are allowed to know <g>.

    Thanks for your suggestion, nonetheless. I do appreciate it.
     
    Edward Diener, Jan 26, 2008
    #7
  8. Edward Diener

    Stevo Guest

    Randy Webb wrote:
    > Thomas 'PointedEars' Lahn said the following on 1/25/2008 6:09 PM:
    > <snip>
    >> You have been warned.

    >
    > "If you don't do exactly as Thomas thinks you should, he will tell on
    > you!". But, he "cares about the Net", he isn't a "control freak".
    > What a joke you are sometimes.


    It would be incredibly amusing if Thomas's CV/Resume had "Good
    communication skills" and "team player" on it. I think his personality
    is more suited to be a traffic warden.

    It's sad when technical knowledge (which none of us doubt he has plenty
    of ... and I expect he has more than me in the web technology field) is
    wrapped up in such a package.
     
    Stevo, Jan 26, 2008
    #8
  9. Edward Diener

    Stevo Guest

    Edward Diener wrote:
    > Stevo wrote:
    >> Edward Diener wrote:

    > The browser ignores the request string
    > part of the URL and continues to reload the image from its cache.


    That doesn't match up with my experience. I've been using that technique
    for a long time. The browser isn't intelligent enough to realize that
    it's the same URL (which of course it isn't).

    > I have to believe that there is some simple way of telling the browser,
    > for a particular web page, to go out and reload the image from its URL
    > rather than assuming it has the most recent version of that image in its
    > cache. The fact that it has been impossible to find out from anyone or
    > anywhere what that way is still amazes me, as if I were asking for some
    > hidden secret which only initiates are allowed to know <g>.
    >
    > Thanks for your suggestion, nonetheless. I do appreciate it.


    Perhaps that Comet Programming thread is something for you. That implies
    the kind of server pushed content updating. That doesn't help you if it
    means you have to re-architect a lot of stuff of course.

    I notice that Yahoo Finance does regular image updates when you're
    looking at a daily stock chart. They could be using some Ajax method, or
    they might just overwrite the innerHTML once a minute by using a
    random query string on the image.
     
    Stevo, Jan 26, 2008
    #9
  10. Stevo wrote:
    > Edward Diener wrote:
    >> Stevo wrote:
    >>> Edward Diener wrote:

    >> The browser ignores the request string part of the URL and continues
    >> to reload the image from its cache.

    >
    > That doesn't match up with my experience. I've been using that technique
    > for a long time. The browser isn't intelligent enough to realize that
    > it's the same URL (which of course it isn't).


    I hear you but unfortunately when I tried this the browser still
    reloaded the image form its cache. The browser could obviously be
    intelligent enough to parse the img tag so that anything after the ? is
    ignored, although it may not be correct HTML to do that. Does it
    actually mean anything to give an image URL some request parameters ?

    >
    >> I have to believe that there is some simple way of telling the
    >> browser, for a particular web page, to go out and reload the image
    >> from its URL rather than assuming it has the most recent version of
    >> that image in its cache. The fact that it has been impossible to find
    >> out from anyone or anywhere what that way is still amazes me, as if I
    >> were asking for some hidden secret which only initiates are allowed to
    >> know <g>.
    >>
    >> Thanks for your suggestion, nonetheless. I do appreciate it.

    >
    > Perhaps that Comet Programming thread is something for you. That implies
    > the kind of server pushed content updating. That doesn't help you if it
    > means you have to re-architect a lot of stuff of course.
    >
    > I notice that Yahoo Finance does regular image updates when you're
    > looking at a daily stock chart. They could be using some Ajax method, or
    > they might just overwrite the innerHTML once a minute by using a random
    > query string on the image.


    I wish your random query string on the image worked for me.

    The only other thing I can think of is that I need a valid expires date
    or last updated date in the content header, and I am not giving one to
    the browsers, so that even though I have the correct cache control
    values the browser still grabs the image from its cache.
     
    Edward Diener, Jan 26, 2008
    #10
  11. Edward Diener

    VK Guest

    > So you are saying that there is essentially no programmatic way of
    > forcing browsers to reload an image from its URL rather than taking
    > the image from its cache ?


    Of cause there is: but it has to be done in accordance with HTTP
    rules, not in the way "it must work by my/his/my boss opinion" ;-)

    Put image content-generating script on your server, ensure - if GET
    used - that for each new image an unique URL is used and be happy.

    myImg.src = "cgi-bin/graph.cgi?p1=v1&p2=v2";
    ....
    myImg.src = "cgi-bin/graph.cgi?p1=v1&p2=v22";
    ....
    myImg.src = "cgi-bin/graph.cgi?p1=v1&p2=v222";
    etc.

    Not a Javascript question per se as Javascript is not in power to
    override HTTP rules or personal browser settings.
     
    VK, Jan 26, 2008
    #11
  12. Edward Diener

    Stevo Guest

    VK wrote:
    > Not a Javascript question per se as Javascript is not in power to
    > override HTTP rules or personal browser settings.


    Yeah, maybe a networking or http forum would be best for that.
     
    Stevo, Jan 26, 2008
    #12
  13. VK wrote:
    > [...]
    > Put image content-generating script on your server, ensure - if GET
    > used - that for each new image an unique URL is used and be happy.
    >
    > myImg.src = "cgi-bin/graph.cgi?p1=v1&p2=v2";
    > ...
    > myImg.src = "cgi-bin/graph.cgi?p1=v1&p2=v22";
    > ...
    > myImg.src = "cgi-bin/graph.cgi?p1=v1&p2=v222";
    > etc.


    This approach will fail in Internet Explorer once the length of the
    *resulting* URI has reached 2083 characters:

    http://support.microsoft.com/kb/208427

    Anyway, it needlessly clutters up the cache, thus potentially *slowing down*
    Web access.


    PointedEars
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
     
    Thomas 'PointedEars' Lahn, Jan 26, 2008
    #13
  14. Edward Diener

    VK Guest

    On Jan 26, 3:28 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    > VK wrote:
    > > [...]
    > > Put image content-generating script on your server, ensure - if GET
    > > used - that for each new image an unique URL is used and be happy.

    >
    > > myImg.src = "cgi-bin/graph.cgi?p1=v1&p2=v2";
    > > ...
    > > myImg.src = "cgi-bin/graph.cgi?p1=v1&p2=v22";
    > > ...
    > > myImg.src = "cgi-bin/graph.cgi?p1=v1&p2=v222";
    > > etc.

    >
    > This approach will fail in Internet Explorer once the length of the
    > *resulting* URI has reached 2083 characters:


    Or even much lesser on Mobile IE. It is a known GET issue for IE.

    > Anyway, it needlessly clutters up the cache, thus potentially *slowing down*
    > Web access.


    No pain - no gain :) If an intensive round-trip traffic is expected
    then another alternative would be to leave document headers in peace -
    they are irreleventa to the issue anyway. Instead OP should set
    expiration headers for _images_ themselves with the expiration date
    guaranteed to be in the past, say:
    Last-Modified: Fri, 31 Dec 1999 00:00:01 GMT
    Expires: Fri, 31 Dec 1999 00:00:02 GMT
    Because HTTP request is rarely goes right from server to client and
    vice versa, Pragma wouldn't hurt neither so to tell to intermediary
    servers do not use their own caches but to forward requests to the
    server of origin, so the full set could be:
    Last-Modified: Fri, 31 Dec 1999 00:00:01 GMT
    Expires: Fri, 31 Dec 1999 00:00:02 GMT
    Pragma: no-cache
    On the long run the answer to OP is "no": one cannot enforce all UAs
    in the whole Internet act exactly in the way your server wants.
    Anything can be changed or overridden client-side. Any WWW project is
    a number game so the question is only to encure the satisfactory
    majority of clients acting in the desired way. If we skip on webpunks
    (Linx, no-cache-if-no-older-than-1998, 64Kb cache size etc), it should
    work for 99,9% of your visitors.
     
    VK, Jan 26, 2008
    #14
  15. VK wrote:
    > [...] Thomas 'PointedEars' Lahn [...] wrote:
    >> VK wrote:
    >>> [...]
    >>> Put image content-generating script on your server, ensure - if GET
    >>> used - that for each new image an unique URL is used and be happy.
    >>> myImg.src = "cgi-bin/graph.cgi?p1=v1&p2=v2";
    >>> ...
    >>> myImg.src = "cgi-bin/graph.cgi?p1=v1&p2=v22";
    >>> ...
    >>> myImg.src = "cgi-bin/graph.cgi?p1=v1&p2=v222";
    >>> etc.

    >> This approach will fail in Internet Explorer once the length of the
    >> *resulting* URI has reached 2083 characters:

    >
    > Or even much lesser on Mobile IE. It is a known GET issue for IE.


    And *you* have suggested this approach anyway. Are you providing evidence
    of your splitted personality here?

    >> Anyway, it needlessly clutters up the cache, thus potentially *slowing down*
    >> Web access.

    >
    > No pain - no gain :) If an intensive round-trip traffic is expected
    > then another alternative would be to leave document headers in peace -
    > they are irreleventa to the issue anyway.


    Yes, but you are missing the point.

    > Instead OP should set expiration headers for _images_ themselves with
    > the expiration date guaranteed to be in the past, say:
    > Last-Modified: Fri, 31 Dec 1999 00:00:01 GMT
    > Expires: Fri, 31 Dec 1999 00:00:02 GMT
    > [...]


    Your ability to repeat *falsely* and *in gibberish* what you read before
    never ceases to amaze me.


    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, Jan 26, 2008
    #15
  16. In comp.lang.javascript message <7ftmj.60185$
    ..net>, Fri, 25 Jan 2008 17:18:56, Edward Diener <diener896092_no_spam_he
    > posted:
    >> See also http://www.mnot.net/cache_docs/
    >> The From header of your NetNews message is invalid too (not to
    >>mention
    >> disregarding Netiquette, see RFC 1036, section 2.1.1 (which refers to RFC
    >> 2822, section 3.4.1), and possibly the Acceptable Use Policy of your Usenet
    >> access provider. Please fix that.

    >
    >Sorry but this is way too cryptic for me. I appreciate your knowledge
    >but I have no idea what you mean by saying the From header is invalid.
    >If you are criticizing my Usenet message to this newsgroup you are just
    >being silly and hypercritical to no good end.



    Ignore the quasi-Kaiser. He has a disturbed personality.

    --
    (c) John Stockton, Surrey, UK. replyYYWW merlyn demon co uk Turnpike 6.05.
    Web <URL:http://www.uwasa.fi/~ts/http/tsfaq.html> -> Timo Salmi: Usenet Q&A.
    Web <URL:http://www.merlyn.demon.co.uk/news-use.htm> : about usage of News.
    No Encoding. Quotes precede replies. Snip well. Write clearly. Mail no News.
     
    Dr J R Stockton, Jan 26, 2008
    #16
  17. Dr J R Stockton wrote:
    > [...] Edward Diener [...] posted:
    >>> See also http://www.mnot.net/cache_docs/
    >>> The From header of your NetNews message is invalid too (not to
    >>> mention
    >>> disregarding Netiquette, see RFC 1036, section 2.1.1 (which refers to RFC
    >>> 2822, section 3.4.1), and possibly the Acceptable Use Policy of your Usenet
    >>> access provider. Please fix that.

    >> Sorry but this is way too cryptic for me. I appreciate your knowledge
    >> but I have no idea what you mean by saying the From header is invalid.
    >> If you are criticizing my Usenet message to this newsgroup you are just
    >> being silly and hypercritical to no good end.

    >
    > Ignore the quasi-Kaiser. He has a disturbed personality.


    Message-ID: <$>

    What a hypocrite you are.


    PointedEars
    --
    Use any version of Microsoft Frontpage to create your site.
    (This won't prevent people from viewing your source, but no one
    will want to steal it.)
    -- from <http://www.vortex-webdesign.com/help/hidesource.htm>
     
    Thomas 'PointedEars' Lahn, Jan 27, 2008
    #17
  18. In comp.lang.javascript message <>, Sun,
    27 Jan 2008 10:23:26, Thomas 'PointedEars' Lahn <>
    posted:
    >
    >Message-ID: <$>
    >
    >What a hypocrite you are.


    I am obliged to you for that further proof of your insanity.

    --
    (c) John Stockton, Surrey, UK. ???@merlyn.demon.co.uk Turnpike v6.05 MIME.
    Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
    Check boilerplate spelling -- error is a public sign of incompetence.
    Never fully trust an article from a poster who gives no full real name.
     
    Dr J R Stockton, Jan 27, 2008
    #18
  19. Dr J R Stockton wrote:
    > [...] Thomas 'PointedEars' Lahn [...] posted:
    >> Message-ID: <$>
    >>
    >> What a hypocrite you are.

    >
    > I am obliged to you for that further proof of your insanity.


    You have said in the referred posting that "You should not use any other
    address that might belong to anyone else, currently or in the future; that
    is wildly inconsiderate, and contrary to the policy of the better ISPs."
    Now, it is entirely possible that someone else has the same idea than
    Mr. Diener and uses that currently non-existing mailbox in the future.

    And that aside, the fact remains that others get spammed because Mr. Diener
    uses an address header that, when used for e-mails by spammers, produces
    bounces, which are received by the people the spammer has selected as source
    for the From header of his spam e-mails.

    However, when others point out the very same problem that you do, in their
    own words of course, you can nothing but insult them in the inept attempt to
    make believe that the opposite would be true.

    So there is sufficient reason to call you an obnoxious hypocrite, indeed.


    EOD

    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, Jan 28, 2008
    #19
  20. Edward Diener

    Ivan Marsh Guest

    On Sat, 26 Jan 2008 04:53:09 -0500, Edward Diener wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> Edward Diener wrote:
    >>> Thomas 'PointedEars' Lahn wrote:
    >>>> The From header of your NetNews message is invalid too (not to
    >>>> mention disregarding Netiquette, see RFC 1036, section 2.1.1 (which
    >>>> refers to RFC 2822, section 3.4.1), and possibly the Acceptable Use
    >>>> Policy of your Usenet access provider. Please fix that.
    >>> Sorry but this is way too cryptic for me.

    >>
    >> You could have used your favorite search engine instead of playing
    >> stupid.

    >
    > It is you who are stupid since clear communication seems beyond you, and
    > you seem to think that cryptic communication is somehow real "cool"
    > rather than just being annoying.


    You're arguing with the single biggest asshole in the group. His nick
    should give you some idea of his attitude. He can't answer a simple
    question without pissing in your face and acting like you should
    appreciate it.

    Even if he was the smartest, most experienced programmer in the group his
    personality would make his advice useless... too bad for him he's not.

    --
    I told you this was going to happen.
     
    Ivan Marsh, Jan 28, 2008
    #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. Oli Filth
    Replies:
    24
    Views:
    982
    Toby Inkster
    Jan 6, 2005
  2. El Kabong

    Browsers, browsers! Quo vadis?

    El Kabong, May 11, 2007, in forum: HTML
    Replies:
    23
    Views:
    944
    dorayme
    May 13, 2007
  3. wardemon

    Cache Images vs Static Images

    wardemon, Jun 14, 2007, in forum: ASP .Net
    Replies:
    3
    Views:
    678
    bruce barker
    Jun 14, 2007
  4. Replies:
    4
    Views:
    800
  5. kaston3
    Replies:
    3
    Views:
    124
    kaston3
    Jul 15, 2006
Loading...

Share This Page