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

[Julian Reschke]

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 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 happen to be aware of the Link header, and the draft (which, by the 
way, was approved a few months ago and already is in the RFC Editor's 
publication queue).

> 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.

If we're talking about the link header primarily, I'd suggest you move 
over to the IETF HTTPbis Working Group's mailing list 
(<http://lists.w3.org/Archives/Public/ietf-http-wg/>).

> ...
> 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.
> ...
> 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?
> ...

The main reason would be "additional complexity" (IMHO). But if we're 
talking about HTTP this mailing list most certainly is not the right 
place to discuss this.

Later on Mike writes:

> Yeah, I'm thinking of servers that can learn and auto-generate these headers.  I think you're thinking of content authors plunking this into their HTML.

So, clarifying: you would send an *additional* Link header for the 
"stylesheet" relation, and augment it with the current etag?

> I'd be perfectly happy to split these out of the HTML-link to the HTTP-link.  Maybe its time they be split up.

I think both should be consistent (like relation type names mean the 
same thing); but that doesn't necessarily mean that their feature sets 
need to be identical.

Best regards, Julian