On Thu, 9 Dec 2010, Roger Hågensen wrote:
On 2010-12-08 20:44, Ian Hickson wrote:
On Mon, 20 Sep 2010, Roger Hågensen wrote:
It would be better to define this as explicitly indicating which
resources are NOT valid any longer, with most sites/web applications
this would only be a select
On 2010-12-08 20:44, Ian Hickson wrote:
On Mon, 20 Sep 2010, Roger Hågensen wrote:
It would be better to define this as explicitly indicating which
resources are NOT valid any longer, with most sites/web applications
this would only be a select few links.
Doing that would require knowing what
On Wed, 15 Sep 2010, Gavin Peters (�~S~K�~V~G彼德�~V�) wrote:
Hi, I'm working on link tags inside of chrome. We're now experimenting
with an optimization that uses link tags and headers to avoid round
trips for cache validation in many cases.
I propose we add an optional etags
On 21.09.2010 21:01, Aryeh Gregor wrote:
On Mon, Sep 20, 2010 at 2:25 AM, Julian Reschke julian.resc...@gmx.de wrote:
Resources that should be cached (stylesheets, images) but change at
unexpected times are indeed a problem.
A well understood approach is to push some kind of version
On 22 Sep 2010, at 22:10, Philipp Serafin wrote:
One disadvantage I think the version-in-URI approach has is that it's
completely transparent to the HTTP caching system. In particular, it
doesn't give caches any information about when a resource is expired.
This isn't really an issue if you
On Mon, Sep 20, 2010 at 2:25 AM, Julian Reschke julian.resc...@gmx.de wrote:
Resources that should be cached (stylesheets, images) but change at
unexpected times are indeed a problem.
A well understood approach is to push some kind of version indicator into
the URI (such as query parameter).
On 19.09.2010 22:33, Robert O'Callahan wrote:
...
So for example, page A links to resource B. The browser does a GET on A,
and receives a document containing a link to B, and the link element
has etags or last-modified attributes. The browser has a cached resource
for B, whose
On 20.09.2010 02:37, Aryeh Gregor wrote:
...
Sure it would. You can currently only save an HTTP request if a
future Expires header (or equivalent) can be sent. A lot of the time,
the resource might change at any moment, so you can't send such a
header. The client has to check every time, and
On Mon, 20 Sep 2010 08:25:09 +0200, Julian Reschke julian.resc...@gmx.de
wrote:
Resources that should be cached (stylesheets, images) but change at
unexpected times are indeed a problem.
A well understood approach is to push some kind of version indicator
into the URI (such as query
On 20 September 2010 01:40, Roger Hågensen resca...@emsai.net wrote:
It would be better to define this as explicitly indicating which resources
are NOT valid any longer,
with most sites/web applications this would only be a select few links.
I like the idea though as it'll allow a page to
On Sun, Sep 19, 2010 at 11:25 PM, Julian Reschke julian.resc...@gmx.dewrote:
On 20.09.2010 02:37, Aryeh Gregor wrote:
...
Sure it would. You can currently only save an HTTP request if a
future Expires header (or equivalent) can be sent. A lot of the time,
the resource might change at any
On 20.09.2010 17:26, Mike Belshe wrote:
...
LINK, in general, allows a server to indicate to a client that it will
need a particular resource earlier than the client otherwise would have
discovered it. Today, the LINK header doesn't assist with understanding
...
Sorry?
That may be a use
Julian,
On 20 September 2010 11:47, Julian Reschke julian.resc...@gmx.de wrote:
Or are you referring to using the Link *header* in addition to an
equivalent HTML LINK?
I think Mike was referring to the Link header. This header is defined in
RFC 2068 (but not RFC 2616) in section 19.6.2.4
2010/9/20 Julian Reschke julian.resc...@gmx.de
On 20.09.2010 17:26, Mike Belshe wrote:
...
LINK, in general, allows a server to indicate to a client that it will
need a particular resource earlier than the client otherwise would have
discovered it. Today, the LINK header doesn't assist
On 20.09.2010 18:17, Gavin Peters (蓋文彼德斯) wrote:
I think Mike was referring to the Link header. This header is defined
in RFC 2068 (but not RFC 2616) in section 19.6.2.4
http://tools.ietf.org/html/rfc2068#section-19.6.2.4 , the most important
part of that text is probably that The Link field is
On 15.09.2010 19:45, Gavin Peters (蓋文彼德斯) wrote:
Hi, I'm working on link tags inside of chrome. We're now experimenting
with an optimization that uses link tags and headers to avoid round
trips for cache validation in many cases.
...
Clarifying: essentially that's a workaround for resources
2010/9/19 Julian Reschke julian.resc...@gmx.de
On 15.09.2010 19:45, Gavin Peters (蓋文彼德斯) wrote:
Hi, I'm working on link tags inside of chrome. We're now experimenting
with an optimization that uses link tags and headers to avoid round
trips for cache validation in many cases.
...
On 19.09.2010 20:47, Robert O'Callahan wrote:
2010/9/19 Julian Reschke julian.resc...@gmx.de
mailto:julian.resc...@gmx.de
On 15.09.2010 19:45, Gavin Peters (蓋文彼德斯) wrote:
Hi, I'm working on link tags inside of chrome. We're now
experimenting
with an optimization
2010/9/19 Julian Reschke julian.resc...@gmx.de
So it's a workaround that causes a performance optimization. It wouldn't be
necessary if the linked resource would have the right caching information in
the first place
I think you're misunderstanding the proposal.
If present for an http uri,
2010/9/19 Julian Reschke julian.resc...@gmx.de:
So it's a workaround that causes a performance optimization. It wouldn't be
necessary if the linked resource would have the right caching information in
the first place.
Sure it would. You can currently only save an HTTP request if a
future
On 2010-09-20 02:37, Aryeh Gregor wrote:
2010/9/19 Julian Reschkejulian.resc...@gmx.de:
So it's a workaround that causes a performance optimization. It wouldn't be
necessary if the linked resource would have the right caching information in
the first place.
Sure it would. You can currently
Hi, I'm working on link tags inside of chrome. We're now experimenting with
an optimization that uses link tags and headers to avoid round trips for
cache validation in many cases.
I propose we add an optional etags last-modified attribute to the link
element. If present for an http uri, these
22 matches
Mail list logo
