| |
In lugnet.dear-lego, Frank Filz <ffilz@mindspring.com> writes:
> David Eaton wrote:
> > Well, it's officially on http://www.lego.com/catalog/ as 4811! Looks like it
> > comes with the black-moustached soldier, plate armor, kettle helm, quiver...
> > with 2 crossbows mounted on a little thingy that spins on a 4x4 black
> > turntable, and has a Leo's Crest shield mounted on the front. (And a small
> > green baseplate). Maybe it'll even come out in polybag form!
>
> TLC really needs to figure out why their pages are getting caught up by
> web caches. From two different machines at work, I see two different US
> catalogs, one with the new sets, one without.
Hmm, most likely, FBOFW, their server isn't probably requesting that the
pages not be cached.
Let's see what's returned over HTTP:
----------------------------------------------------------------------------
% telnet www.lego.com 80
Trying 171.20.249.10...
Connected to lego.com.
Escape character is '^]'.
GET /catalog/amr/product.asp?CurrentItemId=4811
HTTP/1.1 200 OK
Server: Microsoft-IIS/4.0
Date: Thu, 30 Dec 1999 20:41:25 GMT
Connection: Keep-Alive
Content-Length: 12528
Content-Type: text/html
Cache-control: private
<html>
<head>
<title>LEGO Product 4811 Defense Archer</title>
<meta name="keywords" content="LEGO, LEGO Product 4811 Defense Archer">
<link rel="stylesheet" type="text/css" href="/includecss/templatekid.css">
:
:
:
Connection closed by foreign host.
----------------------------------------------------------------------------
According to the white pelican book, the HTTP 1.1 header "Cache-Control:
private" means "This document is not cacheable by a shared cache," which is
different from "Cache-Control: no-cache", which means "Do not cache the
returning document," or "Cache-Control: public", which means "The document
is cacheable by any cache."
That might be the problem . . . .
Anyone know what a "shared cache" is, and, more specifically, what
"Cache-Control: private" means if a cache is not a "shared cache"? I'm
thinkin' a shared cache is something like, for example, a massive AOL proxy
server.
Could be that ISP's are incorrectly caching the documents served by
www.lego.com, and that only private caches such as your browser's cache, or
HTTP proxy server private to you only, are supposed to cache the documents.
In any case, it's probably a Microsoft problem at the heart somehow. ;-)
--Todd
[followups to .publish]
|
|
Message has 1 Reply:
 | | Re: 4811 Defense Archer!
|
| (...) I think that last is perhaps a little unlikely. I'm not sure exactly what the infrastructure of our network here at IBM is, but I strongly doubt there is anything Microsoft between my RS/6000 and www.lego.com. I just did a little bit of (...) (25 years ago, 31-Dec-99, to lugnet.publish)
|
Message is in Reply To:
| | Re: 4811 Defense Archer!
|
| (...) TLC really needs to figure out why their pages are getting caught up by web caches. From two different machines at work, I see two different US catalogs, one with the new sets, one without. Unfortuanately, the machine which sees the new sets (...) (25 years ago, 29-Dec-99, to lugnet.castle, lugnet.dear-lego)
|
13 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
