Delivering the Tk response header via an "http-equiv" meta tag (breaking this out from Issue#5)

[michael-oneill]

Organisations sometimes have to manage several, perhaps thousands, of websites, often developed and maintained by marketing agencies and other contracted parties. Logistically it can be difficult to manage the multiple servers run by these disparate parties in a coordinated way.

An example of where this is required is delivering a Tk response header, especially when the out-of-band consent (OOBC) mechanism must be used. If a user's browser does not support the DNT Exception (Consent) API then the server must determine from the request if tracking consent has been given by that user, before inserting the correct Tk response header. This will in most cases involve looking up the value of an authentication cookie in an external database, and the code to do this would have to reside in the server, and it, or its underlying logic, would have to be shared among the different parties.

This issue can be addressed by explicitly allowing the delivery of Tk responses within the returned HTML content. It is relatively easy to supply a JavaScript library reference to be synchronously loaded by inserted it in every HTML head-section, and this is a well understood industry practice.

This mechanism would only take effect in situations where an origin server did not return a Tk header.

This proposal calls for the ability to declare any Tk response header in an HTML head section using a meta tag with the standard http-equiv attribute.

If a Tk response header exists the meta tag is ignored.

New text to put into TPE:

Tk response header via meta tag

The server MAY supply a Tk response via an HTML meta elements with http-equiv attribute that is an ASCII case-insensitive match for the string "Tk". For example:

Add the following entry to the pragma directives for the [meta](http://www.w3.org/TR/html5/document-metadata.html#the-meta-element) element:

Tracking response (http-equiv="Tk")

If a Tk response header exists abort these steps.

If the Document’s head element is not an ancestor of the meta element, abort these steps.

If the meta element lacks a content attribute, abort these steps.

Let trackingResponse be the value of the content attribute of the meta element.

Authors are strongly encouraged to place meta elements as early in the document as possible, because policies in meta elements are not applied to content which precedes them.

Note: Modifications to the content attribute of a meta element after the element has been parsed will be ignored.

[dwsinger]

Don't think I am the expert on this.

[dwsinger]

Is it already implicitly supported? Can you already use http-equiv for any HTTP header?

[mschunte2]

Let us re-discuss once Roy Fielding joined a call. If there is no blocking factor, I suggest we allow delivery via http-equiv. One question is whether http-equiv should be commonly supported or whether it is an exceptional case for content-security that is not expected to happen for any other headers.

[michael-oneill]

After discussion in the last calls and considering the short timeline which means less time is available that could be spent on more important issues, I withdraw this issue.