Before returning this time value, the servlet rounds
Before returning this time value, the servlet rounds it down to the nearest second by dividing by 1000 and then multiplying by 1000. All times returned by getLastModified()should be rounded down like this. The reason is that the LastModifiedand If-Modified-Sinceheaders are given to the nearest second. If getLastModified()returns the same time but with a higher resolution, it may erroneously appear to be a few milliseconds later than the time given by If-Modified-Since. For example, let’s assume PrimeSearcherfound a prime exactly 869127442359 milliseconds since the beginning of the Disco Decade. This fact is told to the browser, but only to the nearest second: Thu, 17-Jul-97 09:17:22 GMT * A servlet can directly set its Last-Modifiedheader inside doGet(), using techniques discussed in Chapter 5, Sending HTML Information. However, by the time the header is set inside doGet(), it’s too late to decide whether or not to call doGet(). Now let’s assume that the user reloads the page and the browser tells the server, via the If-Modified- Sinceheader, the time it believes its cached page was last modified: Thu, 17-Jul-97 09:17:22 GMT Some servers have been known to receive this time, convert it to exactly 869127442000 milliseconds, find that this time is 359 milliseconds earlier than the time returned by getLastModified(), and falsely assume that the servlet’s content has changed. This is why, to play it safe, getLastModified()should always round down to the nearest thousand milliseconds. The HttpServletRequestobject is passed to getLastModified()in case the servlet needs to base its results on information specific to the particular request. The generic bulletin board servlet can make use of this to determine which board was being requested, for example.
Note: If you are looking for cheap and quality provider to host and run your java application check Astra java hosting services