The browser can use the "If-none-match: <etag>" to request that a 304 response be returned if the object's ETag is the same.
So in this case, it really isn't clear yet whether John's browser had a bug, or IBM's server did, unless you were to look at the headers for the request that returned a stale document. Kirk Wolf Dovetailed Technologies http://dovetail.com On Wed, Mar 29, 2017 at 11:23 AM, Paul Gilmartin < [email protected]> wrote: > On Wed, 29 Mar 2017 10:40:13 -0500, Paul Gilmartin wrote: > > >On Wed, 29 Mar 2017 10:04:37 -0400, John Eells wrote: > > > >>> ... The book has been updated but not the link > >>> to the new level of it. Here is the new level of the book: > >>> http://publibz.boulder.ibm.com/epubs/pdf/e0z3f113.pdf > >> > >>Talking with the person responsible for the book and the link, we found > >>there is a bug in my browser [and R.S.'s?]. It's supposed to compare > >>the page on the web to the cached one and refresh it if they differ ... > > > >Or does it compare a checksum? > > > Looking at the headers: > 568 $ curl -D/dev/fd/3 http://publibz.boulder.ibm. > com/epubs/pdf/e0z3f113.pdf 3>&1 1>/dev/null 2>&1 > HTTP/1.1 200 OK > Date: Wed, 29 Mar 2017 16:08:34 GMT > Last-Modified: Thu, 09 Mar 2017 19:39:09 GMT > ETag: "8cdf2-63c3e-54a516614d140" > Accept-Ranges: bytes > Content-Length: 408638 > Connection: close > Content-Type: application/pdf > > ... The "Etag:" is supposed to take care of that: > https://en.wikipedia.org/wiki/HTTP_ETag > > >SR for the browser? > > > (But would it confess the cached Etag:?) > > -- gil > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
