Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Opt-In by meta-tag #8

Closed
adamdbradley opened this Issue May 1, 2013 · 44 comments

Comments

Projects
None yet
7 participants
@adamdbradley
Copy link

adamdbradley commented May 1, 2013

Building off of an idea from Guy Podjarny (https://twitter.com/guypod/status/329436405447147520) it'd be great to be able to opt-in for CH requests by meta tags.

Developers could place a meta tag within <head> and before any resources, such as:

<html>
<head>
    <meta name="X-CH-Request" content="dw,dpr,t">
    <link href="styles.css" rel="stylesheet" />
</head>
<body>
    <img src="image.jpg">
    <script src="scripts.js"></script>
</body>

In the above, styles.css, scripts.js, and image.jpg would all receive the CH request header. Let's say the client has a device width of 384, device pixel ratio of 2, and supports touch, then this header would be included in each of their requests:

CH: dw=384, dpr=2.0, t

The meta tag would inform the user-agent which header fields it needs to calculate and send with the request. For example, in the meta tag I didn't include the dh field, but did include dw dpr and t. On a standard desktop, even though the meta tag included t, a user-agent which does not support "touch" will know not to send the t field. If the content attribute is missing from the meta tag, or is empty, then the user-agent should send all of the CH fields.

Additionally, I would argue that for step 1 in implementing client hints, that the initial page request (the html page that would contain the meta tag) does not need to receive the CH request header. While there are cases of webpages that include html, javascript and css all in one response, I believe the percentage of these types of implementations are minimal compared to the traditional design (html with external resources using <link href> and <script src>).

One of the biggest reasons NOT to implement client hints is because of the extra bytes we're adding to every request. With this method it allows client hints to be an opt-in feature for resources, but most importantly gives developers valuable information which can be used to reduce sizes of responses, and/or make decisions on the best resource to respond with.

@igrigorik

This comment has been minimized.

Copy link
Owner

igrigorik commented May 6, 2013

Yup, this would be a great addition. A few quick thoughts:

  • There should be a header and a meta-tag opt-in
  • Given the above, the meta tag should use http-equiv
  • X- is deprecated

For simplicity, I wonder if same name could be used in both directions - e.g. CH: dh,dw,dpr on response, as an opt-in mechanism. @mnot any guidance on best practices here?

@mnot

This comment has been minimized.

Copy link
Contributor

mnot commented May 6, 2013

Nice.

You can name them the same, yes, but people might find that confusing, and convention is to use a same-but-different header name (e.g., with the accept-* headers).

I'd use Accept-CH (much like Accept-Ranges).

@igrigorik

This comment has been minimized.

Copy link
Owner

igrigorik commented May 6, 2013

@mnot ah, that makes sense - thanks! +1 for Accept-CH: dh,dw,dpr.

@adamdbradley

This comment has been minimized.

Copy link
Author

adamdbradley commented May 6, 2013

To clarify, opting in to use client hints for page resources could be done with a meta-tag:

<html>
<head>
    <meta http-equiv="Accept-CH" content="dh,dw,dpr">
    <link href="styles.css" rel="stylesheet" />
</head>
<body>
    <img src="image.jpg">
    <script src="scripts.js"></script>
</body>

Alternatively, the request for a page could include an Accept-CH header, such as:

Accept-CH: dh,dw,dpr

I think both the meta-tag and header methods would be great to addition to client hints as either of these could be used as a mechanism to opt-in with. Basically, the world wouldn't be required to add CH headers to every request, but those who do want to take advantage of client hint information can opt-in and use it as a tool to optimize and reduce file sizes.

@igrigorik

This comment has been minimized.

Copy link
Owner

igrigorik commented May 7, 2013

@adamdbradley yep, thanks. Only thing to add: there are good reasons to send CH header on initial request - see #4. For one, until we get good support for Key+Vary, it offers the simplest, 'cache-friendly' deployment strategy.

@guypod

This comment has been minimized.

Copy link

guypod commented Sep 7, 2013

I wasn't aware of this thread, sorry for joining the conversation so late.
FWIW, I do think it's worth including the the CH header on initial requests. As Ilya pointed out in the thread mentioned above, FEO solutions like Akamai's FEO prefer to control which resource to by modifying the HTML, as opposed to modifying the response to the image/resource request itself.

One reason for prefering conditional HTML rewriting to condtional resource rewriting so is carrier proxies - if an image request may return different content based on CH, it can't be cached by a simple/old proxy (you need to return a cache-control: private header). If you instead modify the HTML, the image request itself can be unique (factoring in the CH value), and thus be cacheable by current carrier proxies.

In addition, adding the CH to the initial request has a pretty low cost, as compared to adding it to each sub-resource request (often 100 times as many requests).

As we expand CH, we may find that some CH "fields" don't make sense for the initial request, but for DPR I think it's worth sending it.

@igrigorik

This comment has been minimized.

Copy link
Owner

igrigorik commented Sep 7, 2013

@guypod declaring images as 'private' is one way; the other is to rely on Vary: CH. To start, since we're discussing only sending the dpr value, CH and Vary will work quite well. Further, this is not either or: we should enable both the rewriting applications (e.g. Akamai FEO), and pure image optimization services (e.g. cloudinary, or just my vanilla nginx server) to perform the necessary optimizations -- aka, send CH on both HTML and images.

@guypod

This comment has been minimized.

Copy link

guypod commented Sep 8, 2013

Fair enough, though that's a bit of a short term view, as we all expect CH to expand beyond DPR. In addition, I wouldn't be surprised if certain carrier proxies either ignore Vary or - more likely - treat it the same a "private" instruction.

Lastly, some optimizations, like versioning, require changing the actual file name to apply. If versioning is achieved by adding a hash of the file's content to the URL/query, and that hash changes depending on the CH value, you have to start using more elaborate logic - which would not be needed if you rewrote the HTML instead with the CH value in mind.

To be clear, I'm advocating here for:

  1. Sending CH on initial request
  2. Sending CH on subsequent requests only if the containing page opted in

So all use-cases should be supported, but an image optimization service would require their clients to add the opt-in to their pages too.

@igrigorik

This comment has been minimized.

Copy link
Owner

igrigorik commented Sep 8, 2013

Well, I'm not going to die on this hill, but the more I think about it, the more I grow convinced that the extra complexity of (2) is not worth it. We're talking about 11 bytes of data in upstream on HTTP 1.x, and 11 bytes per connection for HTTP 2.0... HTTP is stateless, and the CH header should be sent on all image requests at a minimum (just like Accept), and ideally on all requests.. All we're doing here is creating another adoption hurdle -- which is also unnecessary in the longer term (HTTP 2.0).

@guypod

This comment has been minimized.

Copy link

guypod commented Sep 8, 2013

First of all, you're talking about roughly 1100 upload bytes per page load for the average page. Still not huge, but not 11 bytes.

Second, I tend to agree these 11 bytes aren't a big deal, but I thought were discussing CH here, not just DPR. Whatever we do here would become a fact we can't change later, and when we want to add other client hints the bloat would become more severe. If we want to stop at DPR, lets make this a DPR header, not a CH header with a DPR value.

As for http/2, I expect there'll be at least 5-10 years until the majority of websites use it, so I don't think we can justify adding bloat to http/1.1 on that premise.

On Sat, Sep 7, 2013 at 11:02 PM, Ilya Grigorik notifications@github.com
wrote:

Well, I'm not going to die on this hill, but the more I think about it, the more I grow convinced that the extra complexity of (2) is not worth it. We're talking about 11 bytes of data in upstream on HTTP 1.x, and 11 bytes per connection for HTTP 2.0... HTTP is stateless, the CH header should be sent on image requests at a minimum (just like Accept), and ideally on all requests.

Reply to this email directly or view it on GitHub:
#8 (comment)

@yoavweiss

This comment has been minimized.

Copy link
Contributor

yoavweiss commented Sep 8, 2013

Fair enough, though that's a bit of a short term view, as we all expect CH to expand beyond DPR. In addition, I wouldn't be surprised if certain carrier proxies either ignore Vary or - more likely - treat it the same a "private" instruction.

That's true, but providing a "vary friendly" use-case, where vary support makes an actual difference (unlike "vary: User-Agent") might help to change that.

I think that the key here is keeping CH sending only a single value.

Today that single value is DPR.
As I've already discussed with Ilya on Blink-dev, I think that for viewport res-switching, we need a new unit that represents "device pixels in viewport width", perhaps divided by some fixed value, to reduce variance.
That unit will enable CH to send a single value that represents the maximum number of pixels of the optimized image.
I believe that the same unit will also be extremely useful as a srcset qualifier.

Regarding an opt-in mechanism, I'm not 100% sure it is essential, but if we're going to implement one, I believe it should be HTTP based (with meta http-equiv being it's markup twin), and it can also serve another purpose: letting the server decide which hints it wants to opt-in to. That may be important once CH goes beyond res-switching.

@yoavweiss

This comment has been minimized.

Copy link
Contributor

yoavweiss commented Sep 8, 2013

FEO solutions like Akamai's FEO prefer to control which resource to by modifying the HTML, as opposed to modifying the response to the image/resource request itself.

Wouldn't that specific use-case be better satisfied by srcset? What are the advantages of CH here?

@kornelski

This comment has been minimized.

Copy link

kornelski commented Sep 8, 2013

Since the default is to send CH:, this meta seems more like opt-out rather than opt-in. CH: dpr=2 is not so bad, so removing it with extra meta may be not worth it. If CH: gains more verbose properties in the future, then maybe it will be needed.

HTTP requests are supposed to be independent from each other, so it's a bit weird that header in one response affects headers in other requests (although if Vary: is used properly it would be correct).

What if two pages have different meta, but include same image URLs? Does it also affect hotlinked images? (given that Vary: isn't really usable, mere Cache-Control: private would allow mixed-up local caches)

@guypod

This comment has been minimized.

Copy link

guypod commented Sep 8, 2013

@pornel AIUI the intent of this issue is to make the default behavior NOT to send CH, thus making it an opt-in.

@yoavweiss yes, for DPR specifically, srcset would alleviate the need for HTML rewriting. But I'm thinking of the broader CH here.

I think the disagreement here revolves around the future of CH.
If we plan to expand CH (and there are many use-cases for it), then bloat would become a significant concern. Changing the default to be opt-in only then would not be an option (due to backward compatibility), so we need to design the solution now to address that future concern.

If we don't plan to expand CH, then at the very least we should rename it to DPR, and at most we should drop it altogether given the lack of future expansion plans.

@yoavweiss

This comment has been minimized.

Copy link
Contributor

yoavweiss commented Sep 8, 2013

If we plan to expand CH (and there are many use-cases for it), then bloat would become a significant concern. Changing the default to be opt-in only then would not be an option (due to backward compatibility), so we need to design the solution now to address that future concern.

Makes sense.

My main concern regarding a CH header with multiple values is the fact that key support will take many years to be supported by caches, leading to uncacheable resources, even if vary is supported.

An opt-in mechanism, that enables the server to indicate the hints it needs to rely on, making sure that the client only sends those hints, will mitigate that concern.

So, 👍 for an opt-in mechanism

@kornelski

This comment has been minimized.

Copy link

kornelski commented Sep 8, 2013

@guypod ah, ok. I must have misread it then. So opt-in, especially to specific properties, makes sense.

This alleviates some of my concerns that UA doesn't know what server may be looking at, so it would have to invalidate too much too often (e.g. if viewport was ever added, you wouldn't want to reload all images whenever you resize the window).

@kornelski

This comment has been minimized.

Copy link

kornelski commented Sep 8, 2013

edit: nevermind, I was going to say HTML may need CH itself for art-directed use-cases, but realized that without <picture>-like solution it won't work well anyway.

@igrigorik

This comment has been minimized.

Copy link
Owner

igrigorik commented Sep 8, 2013

@pornel: you would end up with two different entries in your cache - potentially with same file (e.g. both 1x). The CH value is part of the cache key with Vary..

@yoavweiss @guypod I think we've gone around full circle here, but still missing a few things. Let me try to tease the different threads apart...

a) Opt-in: If you start with "off" and require that the site performs an explicit opt-in, then we've just introduced an extra RTT into equation - aka, we're looking for Accept-CH from the server, or same meta-equiv. The major disadvantage here is that this disallows FEO solutions from applying their rewriting logic on the markup itself -- e.g, PageSpeed, Akamai FEO, etc. This is a big loss in functionality. More discussions on this in #4.

b) Declaring which variables you care about: assuming we add more variables to CH over the long-term, some sites may or may not care about all of them. An additional mechanism like @mnot's browser-hints or Accept-CH could be used here to declare the variables you want - e.g., if my site wants to know the dpr only, then I could advertise that as Accept-CH: dpr and corresponding meta-equiv on the initial response.

To address the use case of HTML rewriting, as well as the fact that HTTP is stateless, perhaps a better approach would be to use an "opt-out", instead of an opt-in:

  • The UA always sends CH with variables it supports - i.e. initial request to any resource.
  • The site can opt-out out of CH, or ask the UA to only send some CH variables, by using Accept-CH mechanism. Aka, we're inverting the problem: if the site does not care for CH, it will still get the CH header on initial request (which allows FEO solutions to do their work), but then it can disable or customize CH for all subsequent resources on the page.
@kornelski

This comment has been minimized.

Copy link

kornelski commented Sep 8, 2013

Is automatic optimization even a use-case for CH? With incorrect intrinsic size it's inherently unsafe (e.g. what about games that display images on canvas? Rewriting drawImage() calls would be at least very tricky)

@igrigorik

This comment has been minimized.

Copy link
Owner

igrigorik commented Sep 8, 2013

@pornel yes it is a major use case. Automatic rewriting has its limits, but it's in use by millions of sites. Further, in absence of Key (or until we land support for it), it is also a way to safely customize the page based on more than just the dpr variable.

@kornelski

This comment has been minimized.

Copy link

kornelski commented Sep 8, 2013

@igrigorik so I don't see how it would work safely. Surely it's much less work and guaranteed safety if you just inject srcset instead of injecting width/height and background-size and changing images that could be used by JS with other markup or code you can't rewrite?

@igrigorik

This comment has been minimized.

Copy link
Owner

igrigorik commented Sep 8, 2013

@pornel I think this is a tangent. We should debate merits and pitfalls of automated FEO rewriters in a separate thread. I'll just point out that in practice these solutions are used and deployed very widely and it is a use case we can't rule out - to mitigate your specific example, some provide additional syntax to opt-out specific resources from rewriting, others allow you to toggle specific filters, etc. Also, note that it doesn't have to be a proxy.. my origin server could be "CH-aware" and produce markup that's customized to the client with full awareness of other things it may affect by doing so.

@guypod

This comment has been minimized.

Copy link

guypod commented Sep 8, 2013

@igrigorik:

re (a), I don't understand why you think rewriters won't be able to leverage CH.
As I pointed out above, I'm suggesting that we do send the CH header with initial requests (by which I mean the parent request of a page or possibly frame), but we do not send the CH header with other requests unless opted in.
Rewriters who care about CH can rewrite the HTML using the CH value they received in the initial request and/or choose to opt-in if they want to optimize per resource.
Since the opt-in would be in an HTTP header or a tag in the HTML, you don't need an extra RTT to opt-in.

re (b), I really like @mnot's Browser Hints, but note that in its current form it's done via a side request, not inline (unless I'm out of date here). This means a website can't rely on the browser getting the browser hints before requesting resources. What I'd love to see is a modified Browser Hints implementation which supports a hybrid of inline hints (e.g. an "Accept-CH" response header/meta-equiv) and async ones (for more elaborate hints which don't need to be sync). If anything, I'd opt for implementing the former before the latter.

Lastly, re the opt-out, IMO that misses the whole point of avoiding bloat.
As you know, the vast, vast majority of websites would never know nor use CH, and let alone know to opt-out and how to do so, at least for a good number of years. For those sites, we'll be introducing bloat with zero value, which is my concern.

IMO the compromise of sending CH by default with the initial request + the opt-in mechanism to be a good one, as it supports pretty much all the use-cases (except image manipulation services that can't get the website owner to opt-in), and yet doesn't create too much bloat (since initial requests make up on 1-2% of total requests).

@igrigorik

This comment has been minimized.

Copy link
Owner

igrigorik commented Sep 8, 2013

@guypod I think I may have misunderstood your earlier proposal then.. I think we're on the same page: (a) we want the CH hint on initial request; (b) we want a mechanism to toggle CH on/off for resources on the page. I guess you're suggesting the default is "off", whereas my last suggestion was "on" followed by opt-out.

To be explicit, I think your proposal is:

> GET /page.html HTTP/1.1
> CH: dpr=2.0 (always present on initial request)
> ...

< 200 OK HTTP/1.1
< Accept-CH: dpr
< (response)

Same could be achieved with http-equiv meta tag. If Accept-CH is present in the response, then CH hints are also sent for resources as well. Correct? I think that would work and it addresses both use cases.

@guypod

This comment has been minimized.

Copy link

guypod commented Sep 8, 2013

@igrigorik Yep, we're on the same page now, your suggestion looks great to me.

@mnot

This comment has been minimized.

Copy link
Contributor

mnot commented Sep 9, 2013

@guypod said earlier:

"If we want to stop at DPR, lets make this a DPR header, not a CH header with a DPR value."

I'm very +1 on that; it avoids waiting for the Key header. It also means that the bar for starting a new client hint is just the same as for any header; you have to justify it on its own.

The motivation for a CH header as I understood it was to save bytes, presuming a lot of them. However, consider:

CH: dpr=1\r\n    [11 bytes]
DPR: 1\r\n       [8 bytes]

Even with three (adding fictional "foo" and "bar" hints):

CH: dir=1, foo=2, bar=3\r\n  [25 bytes]

vs.:

dpr: 1\r\n
foo: 2\r\n
bar: 3\r\n   [24 bytes]

Of course, there are ways to save bytes in both encodings, but the point is that you really only see significant returns when there are a lot of really small values; really, you're comparing:

ch_approach_overhead = ch_header_name + header_colon + ((comma_delimiter + equal) * num_ch) + line_delimiter
single_approach_overhead = (header_colon + line_delimiter) * num_ch
ch_header_name = 2  # CH
header_colon = 2  # ": " - can be 1 if you drop the space
line_delimiter = 2  # "\r\n" - can be 1 if you just do "\n"
comma_delimiter = # 2 ", " - can be 1 if you drop the space
equal = 1  # the equals sign
@mnot

This comment has been minimized.

Copy link
Contributor

mnot commented Sep 9, 2013

@guypod Browser Hints is now a response header, not a separate request; see
http://tools.ietf.org/html/draft-nottingham-http-browser-hints-05

@guypod

This comment has been minimized.

Copy link

guypod commented Sep 9, 2013

@mnot cool, thanks for the update. In that case, it seems like a great fit for the opt-in for HTTP. Would it also be supported in an http-equiv meta tag?

@igrigorik

This comment has been minimized.

Copy link
Owner

igrigorik commented Sep 9, 2013

Silly question, assuming we have a "DPR" header, what's the proper opt-in http-equiv?

<meta http-equiv="Accept-DPR" content="?">

@guypod

This comment has been minimized.

Copy link

guypod commented Sep 9, 2013

@mnot the header-per-hint option is being discussed in #14.

@igrigorik If we use the approach in #14, you'd use one client-hints model for all the hints, so you'd still have one opt-in for the hints you're interested in, despite the fact they'll be sent as separate headers.

For instance:

<meta http-equiv="Accept-CH" content="dpr,x,y">

Would result (assuming #14 is applied) in a request like:

GET / HTTP/1.1
CH-dpr: 2
CH-x: 4
CH-y: 9
...
@mnot

This comment has been minimized.

Copy link
Contributor

mnot commented Sep 10, 2013

Some of the feedback I've received on Browser Hints has been that it'd be nice to have a generic way to say "please send these headers." Not all of BH can be accommodated by that (indeed, much of it is "please don't send these headers") but it may be worth doing something like:

Accept-Req: dpr

I think what #14 is really getting at is that HTTP request headers by their very nature are client hints, so there's no real need to hide them inside another header. Making the opt-in slightly more generic like this feels better to me. YMMV.

igrigorik added a commit that referenced this issue Sep 17, 2013

first cut at draft-2
- Split CH header into multiple CH-{name} pairs (issue #14)
- Define Accept-CH opt-in mechanism (issue #8)
- Added server hint confirmation section
@igrigorik

This comment has been minimized.

Copy link
Owner

igrigorik commented Sep 17, 2013

@guypod

This comment has been minimized.

Copy link

guypod commented Sep 17, 2013

Looks pretty good to me. A couple of comments:

  1. You didn't explicitly state the client should send all CH headers with the initial request, or even mentioned this possibility. Is that intentional?
  2. If we don't require (1), do we want to add a TTL to the Accept-CH Header? In general, what's the scope of the Accept-CH repsonse header?
@igrigorik

This comment has been minimized.

Copy link
Owner

igrigorik commented Sep 17, 2013

  1. Yes, that's intentional. This may be a necessary concession to address existing concerns over initial deployment risks -- adding default headers has a very high barrier to entry. Conversely, if the header is based on opt-in, then it only needs to be sent to sites that explicitly ask for it: initial request is empty, but returns the opt-in, which then triggers CH on all requests originating from that page.

  2. Yes, in theory you could "remember" the preference - ala Alternate-Protocol. Having said that, this is less of a spec issue and more of an implementation question. By default, I think you can implement a reasonable version without any TTL's: server opt-in for the pages it wants to use CH for, and browser appends CH to all subresource requests originating from that page.

@yoavweiss

This comment has been minimized.

Copy link
Contributor

yoavweiss commented Sep 18, 2013

  1. Yes, that's intentional. This may be a necessary concession to address existing concerns over initial deployment risks

I think that is a very good compromise.

  1. Yes, in theory you could "remember" the preference - ala Alternate-Protocol. Having said that, this is less of a spec issue and more of an implementation question.

I think it's worth while to add such "preference caching" to the spec, while making it optional. It would allow browsers to do that while being compliant with the spec, and define a TTL mechanism of some sort for the site's preference.

Otherwise, I'm afraid that optimization providers that want to manipulate the HTML according to CH headers won't be able to do that on the main HTML, only on sub-resources.

We also need to consider the "scope" of opt-in. If the home page has opted-in, does it imply that followup pages on that sites are opted in by default?

@igrigorik

This comment has been minimized.

Copy link
Owner

igrigorik commented Sep 19, 2013

I think it's worth while to add such "preference caching" to the spec, while making it optional. It would allow browsers to do that while being compliant with the spec, and define a TTL mechanism of some sort for the site's preference.

I've kept it brief, but added a short snippet to address this: 1505431#L0L159

We also need to consider the "scope" of opt-in. If the home page has opted-in, does it imply that followup pages on that sites are opted in by default?

Without "remembering" the answer is simple: every page that wants to opt-in must provide the header. With memory, yes, I think it would apply to entire origin wide... but practically speaking, you'll still have to provide it on every page anyway, since you can't control which page the user may land on.

@jansepar

This comment has been minimized.

Copy link

jansepar commented Sep 24, 2013

@igrigorik I noticed that draft 2 had no mention of the meta tag opt-in, and from reading the conversation here it doesn't seem like it was abandoned. I think that the ability to opt-in with a meta tag as an alternative from opting in via confirmation from the server is really important, so just making sure it's still on the radar!

@igrigorik

This comment has been minimized.

Copy link
Owner

igrigorik commented Sep 24, 2013

The opt-in is defined here: https://github.com/igrigorik/http-client-hints/blob/draft2/draft-grigorik-http-client-hints-01.txt#L290

The equivalent of sending the header is using <meta http-equiv=...>, which is a standard mechanism, hence I didn't enumerate it explicitly and not sure if that's really needed...

@kornelski

This comment has been minimized.

Copy link

kornelski commented Sep 24, 2013

http-equiv in HTML5 has narrower definition: http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#concept-http-equiv-extensions

and requires all values to be registered:
http://wiki.whatwg.org/wiki/PragmaExtensions

Are there use-cases for <meta>? Can we assume that if somebody is able to use CH headers they can output the accept header as well?

@adamdbradley

This comment has been minimized.

Copy link
Author

adamdbradley commented Sep 24, 2013

My first thought would be for users of shared CMS's, such as wordpress.com or wix.com. I would imagine there are plenty of systems out there which knowledgeable designers will be using but would not have server-side control. While it may not be the preferred option for most large scale implementations, I don't think we should purposefully exclude the <meta> opt-in.

@jansepar

This comment has been minimized.

Copy link

jansepar commented Sep 24, 2013

@adamdbradley agreed, having both ways of opting would be ideal. For third party image resizing solutions that don't have access to the users backend (say, a solution that got users to prefix all of their images like imageresizier.com/?imgUrl=www.example.com/foo.png), it would be much easier to ask the user to insert a meta tag, rather then informing them what headers they need to set in their http server.

@igrigorik

This comment has been minimized.

Copy link
Owner

igrigorik commented Sep 24, 2013

When I said "not sure if its really needed", I didn't mean if we need http-equiv.. rather, explicit language in the spec for it. With that said, seeing the confusion: a47b03b.

@jansepar

This comment has been minimized.

Copy link

jansepar commented Sep 24, 2013

Great thanks for the clarification!

@igrigorik

This comment has been minimized.

Copy link
Owner

igrigorik commented Oct 25, 2013

v1 draft defines opt-in mechanism via meta tag, plus via HTTP header:
https://github.com/igrigorik/http-client-hints/blob/master/draft-grigorik-http-client-hints-01.txt#L295

Closing the issue -- please reopen if anything is unclear.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.