Announcement

Collapse
No announcement yet.

Cache / Headers > Prevention?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Cache / Headers > Prevention?

    Okay, so let's start from the begining


    HOW DO you write in the CODE when authoring for webpages (.html files only, nothing for PHP, CFM or ASP) to prevent caching.

    I only experience caching behind a proxy on plain .html files or websites that contain Flash Movies embedded into .html files. I have no problems in caching for .php files (ie vbulletin, phpbb, etc)

    I cannot find documentation about what Cosmos is proposing and this problem ONLY occurs for me for .html files even with the pragma no cache meta tags in the headers.

    What "code" is Cosmos talking about and where can we research this on the net?

    So as nice as Cosmos put it in the other thead, what is the code that I would put into a .html document that will control the cache?
    Where does it go? Between the <head></head> tags? Before the <html> tag?
    Last edited by WizyWyg; Sun 25th Nov '01, 12:13pm.
    There are only 10 types of people in the world: Those who understand binary, and those who don't


  • #2
    The code he is talking about is what is returned when your browser asks the server for a file. It is commonly known as the HTTP headers.

    I'm not sure there is any way to do it with straight HTML, because there is no function with HTML to send headers at the point that you would need to. The proxy does not look inside the HTML file - at that point it is too late.

    I know with PHP you use the Header() function to set HTTP headers, but I'm not sure of any way to do it without some kind of server-side scripting language.

    Comment


    • #4
      Okay, just proves that what i have been saying all along is that there is no definite way to take care of any caching problems.

      Sure it can do it in php, but it doesn't solve the problems for normal websurfing on normal .html files. Since the only caching problems i have is with "normal" .html files and some pages with embeded flash files.

      (sorry i haven't read the links yet, but I will look into them)
      Last edited by WizyWyg; Sun 25th Nov '01, 9:17pm.
      There are only 10 types of people in the world: Those who understand binary, and those who don't

      Comment


      • #5
        With standard HTML pages it would need to be configured at the server level. With vB it could be done within the code because of PHP's header() function.

        Comment


        • #6
          Originally posted by tubedogg
          The code he is talking about is what is returned when your browser asks the server for a file. It is commonly known as the HTTP headers.
          Correct. When you retrieve a HTML file over the web, the server sends two things: first the HTTP header and then the HTTP body. The HTTP body includes the file you've asked for, in this case the HTML file.

          I'm not sure there is any way to do it with straight HTML, because there is no function with HTML to send headers at the point that you would need to. The proxy does not look inside the HTML file - at that point it is too late.
          Absolutely correct!

          I know with PHP you use the Header() function to set HTTP headers, but I'm not sure of any way to do it without some kind of server-side scripting language.
          That's not the way I would do that!

          In the other thread I've informed you that one can achieve two things (not related to vBulletin at all!):
          • Improve your site's perceived (and true) responsiveness while reducing its load at the same time (!!!)
          • Solve some caching problems.

          For both of these things to happen, both the following constraints should be true:
          1. We are talking about an Apache server (since I am knowledgeable on that one, as well as Jigsaw/CERN)
          2. You can change the web server's configuration (like which modules are loaded).

          If both of the above are true, then we can continue the conversation.

          BTW, the only authoritative source for HTTP is IETF draft standard RFC2616.

          PS: More or less this means that if you write plain flash files or plain (non-CGI/PHP/ASP/JSP) HTML pages, or graphics files you can not control expiration/caching unless you can modify the web server's configuration a bit.
          Last edited by cosmos; Sun 25th Nov '01, 11:51pm.

          Comment


          • #7
            Okay then that just plain says it all.

            Its a server level thing (and if a server is not set up to handle regular .html files in caching) then anyone "browsing" that website will have problems in viewing normail websites.

            So, my conclusions:

            1. there is no absolute way to control caching.
            2. php can handle caching through coding.
            3. proxy servers suck (okay my opinion ^_~)

            So, explain to me why I have problems with .html files but have no problems with vbulletin sites (with the current setups), even if they are run from the same domain?
            There are only 10 types of people in the world: Those who understand binary, and those who don't

            Comment


            • #8
              Originally posted by WizyWyg
              Its a server level thing (and if a server is not set up to handle regular .html files in caching) then anyone "browsing" that website will have problems in viewing normail websites.
              Not completely. I assume that as a content creator you do have permissions to upload files to the server, correct? If you do and the web server admin has included (per request perhaps) module mod_headers then you can control caching of any file (html, gif, swf...) without changing the server's configuration.

              So, my conclusions:

              1. there is no absolute way to control caching.
              Quite a general remark. Canot comment here.
              2. php can handle caching through coding.
              Correct, as well as CGI/ASP/JSP/servlets...

              3. proxy servers suck (okay my opinion ^_~)
              No, no, NO! It is just that web content creators are (mis-)guided by M$/Netscape "guidelines"! In essence, proxy servers can be used to your and the surfer's advantage!

              So, explain to me why I have problems with .html files but have no problems with vbulletin sites (with the current setups), even if they are run from the same domain?
              Simple! Plain HTML files or any other "plain" (gif, jpeg) file is emitted to the client with a "Last-modified" date included in the HTTP head. If no Cache-Control/Pragma/Expires directive is supplied in the same header you would imagine that this URL would be considered "stale" by a proxy middle... Wrong! In the HTTP specification for this scenario it is allowed by the proxy server to apply this sort of "heuristic" expiration, usually 10% of the difference (current-date) - (URL's Last-modified value). So if a proxy downloads on July 1st, 2001 a page last modified on January 1st, 2001 then it can cache it for an interval of 10% x (6 months)= 16-17 days.

              PHP/CGI and dynamic scripts in general do not specify a Last-Modified value, which makes it difficult for proxies to implement a "heuristic" expiration algorithm. It doesn't mean that proxies don't exist that can assign an ad hoc expiration value.

              Comment


              • #9
                Originally posted by cosmos


                Simple! Plain HTML files or any other "plain" (gif, jpeg) file is emitted to the client with a "Last-modified" date included in the HTTP head. If no Cache-Control/Pragma/Expires directive is supplied in the same header you would imagine that this URL would be considered "stale" by a proxy middle... Wrong! In the HTTP specification for this scenario it is allowed by the proxy server to apply this sort of "heuristic" expiration, usually 10% of the difference (current-date) - (URL's Last-modified value). So if a proxy downloads on July 1st, 2001 a page last modified on January 1st, 2001 then it can cache it for an interval of 10% x (6 months)= 16-17 days.

                PHP/CGI and dynamic scripts in general do not specify a Last-Modified value, which makes it difficult for proxies to implement a "heuristic" expiration algorithm. It doesn't mean that proxies don't exist that can assign an ad hoc expiration value.

                Okay, then I want to know why fusion is the only person experiencing these problems with vbulletin behind a proxy on a public computer, yet my setup and accessing these forums are not producing these same results which is also behind a proxy and a firewall? ALL vbulletin sites cannot have made these "changes" in the php header() coding because I KNOW some of them know squat about php and I have no problems with their boards (with logging out and logging back in or "reclaiming" sessions)

                Im talking about "other" websites, not my own when it comes to caching of .html and flash files. So how can I take care of that problem? Since I have no control over their servers.
                Last edited by WizyWyg; Mon 26th Nov '01, 2:40am.
                There are only 10 types of people in the world: Those who understand binary, and those who don't

                Comment


                • #10
                  WizyWyg, it could be as simple as my setup is just quirky enough to trigger this error (Note, I'm able to do it on several sites). That I'm virtually alone in doing it, doesn't mean there isn't something very wrong with how vBulletin is currently doing these checks, it just means I'm the unlucky catalyst.
                  Toddler from Hell

                  Comment


                  • #11
                    Originally posted by WizyWyg
                    Okay, then I want to know why fusion is the only person experiencing these problems with vbulletin behind a proxy on a public computer, yet my setup and accessing these forums are not producing these same results which is also behind a proxy and a firewall?
                    Because the specific proxy cache in Fusion's case assumes that the content cached could be cached much longer that it should. Per HTTP specification, it is up to the proxy cache implementor/configurator to decide for how long items should be cached.

                    But think for a while why these problems appear in the first place: because a URL's expiration is not explicitly sent in the HTTP response associated with it.

                    The usual questions I always pose on myself, when placing content on a web server: should this file be cached? If yes, for how long would it be allowed for a client/proxy to hold it before asking for the same file again (alternatively, for how long should the file be considered unchanged)? Is this information private? If so, is it acceptable to allow caching on "private" caches?

                    ALL vbulletin sites cannot have made these "changes" in the php header() coding because I KNOW some of them know squat about php and I have no problems with their boards (with logging out and logging back in or "reclaiming" sessions)
                    I see. Yet the appearance of a problem is not related to its presence. It might show up, then again it might not. Does this mean that this is not a problem after all?

                    Im talking about "other" websites, not my own when it comes to caching of .html and flash files. So how can I take care of that problem? Since I have no control over their servers.
                    BTW, do you have direct control over your site's web configuration?
                    Last edited by cosmos; Mon 26th Nov '01, 3:08am.

                    Comment


                    • #12
                      On the proxy server? No I dont have access since we are just working off of the server which is setup in a whole different country
                      There are only 10 types of people in the world: Those who understand binary, and those who don't

                      Comment


                      • #13
                        ok cosmos, what are the possibilities, of the cookie paths, or the cashe sessions time limit length, that are in the admin control panel. Could some of those be used to combat some of these problems? How about something as simple, as turning on the regular HT headers, even though not all servers support that particular method?

                        it sounds to me, that if it is a session timeout problem, than a cookie timeout limit could be set lower...

                        Comment


                        • #14
                          Originally posted by WizyWyg
                          On the proxy server? No I dont have access since we are just working off of the server which is setup in a whole different country
                          Not on the proxy, but on the web server itself.

                          @Tora-tora: Are you talking about the cookies/security issue discussed in the other thread or about improving bandwidth use for your site here?

                          @Tubedogg: I understand that and had my doubts about posting this here. Yet, I feel like that a content creator who understands some delicate issues on HTTP cache manipulation is simply unbeatable, with regard to his control over content distribution and bandwidth optimization. The roles of web server "tuner" and content creator should be close enough. Ideally, they should be enforced by the same person.

                          Comment


                          • #15
                            Originally posted by cosmos
                            BTW, the only authoritative source for HTTP is IETF draft standard RFC2616.
                            It may be the 'official' source, but it ain't exactly easy reading for someone who is just learning about it.

                            Comment

                            Working...
                            X