[whatwg] Proposal: add attributes etags & last-modified to <link> element.

[Gavin Peters (蓋文彼德斯)]

Julian,

On 20 September 2010 11:47, Julian Reschke <julian.reschke at 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
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 semantically
equivalent to the <LINK> element in the HTML.  There's also a pending
internet draft which expands more fully on this header:
https://datatracker.ietf.org/doc/draft-nottingham-http-link-header/ , and
that draft in the HTTP case maintains the HTML equivalence (see section 5 of
the internet draft).

I think the HTML link element is unusual because it does exist both in
markup, and at the protocol level.  My experimentation with these attributes
has been entirely at the protocol, and not the markup level.  The standard
for the element is in HTML, and so that's why I made my proposal here in
whatwg.

 existing cache control mechanics, so if the browser does have the
>> resource in cache but it needs validation, you didn't accomplish what
>> you had hoped with the LINK header - the client is still going to make a
>> costly round-trip.  For savvy content authers, they could, as you
>> suggest, simply modify the content to work with this case.  This
>> effectively restricts the full benefit of LINK to the subset of
>> resources which are static and have long-lived expiry.  That would leave
>> LINK less useful to large swaths of the internet where they do leverage
>> if-modified-since and etags.
>>
>
> Link relations cover many other use cases than those that you seem to be
> considering.
>
> For resources that change infrequently but at unexpected times, it's
> already possible to get what you want by varying the URI when the resource
> changes (such as putting a timestamp or a revision number into a query
> parameter).


Those approaches work; but require modifying the HTML.  So if a server is
attempting to have good protocol-level support for the Link header, and to
help a client avoid redundant fetches, we're now requiring information leak
from the protocol level down to the markup level.  I think this problematic,
too.  If the link element is going to work as both a header and an element,
it should have sufficient flexibility to be useful and fully embedded in
each application.

 Rather than ask this question about the LINK header attributes, you
>> could instead aim your question at HTTP - why does HTTP bother with
>> if-modified-since?    But the answer is moot - that decision was made
>> long ago.
>>
>
> Not sure what you're referring to. If-Modified-Since predates ETags (as far
> as I recall).



> Given that the web *does* use these basic cache control mechanisms, why
>> *wouldn't* you want the LINK header to be capable of using them too?
>>  :-)  This proposal is actually just making LINK more like the rest of
>> HTTP.
>>
>
> My main concern is that if we put etags into *HTML* links, we're leaking
> protocol-level information into markup. I think it would be good if we could
> avoid that, and so far I haven't seen any use case that doesn't work
> without.
>

I think Mike was speaking about conditional gets generally, which can of
course be conditioned on ETag or Last-Modified.  Most web browsers, when
they have expired cache data, will make a conditional get based on their
existing cache entry.  If these attributes give a way to avoid this extra
request, and if these attributes enhance the protocol-level context, why not
support them?

- Gavin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100920/80aa355c/attachment-0002.htm>