Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Content negotiation and CDNs #10

Closed
marcoscaceres opened this Issue · 16 comments

8 participants

@marcoscaceres

David Demaree wrote:

Just to offer some insight on this, given that I work on a product (Typekit) that is all about content negotiation, one reason I'm a strong proponent of doing this in the client is that server-side techniques can become very difficult — and very costly — at scale. I wrote a post for our blog last year about why we use JavaScript-based client-side content negotiation for web fonts instead of doing it on the server: http://blog.typekit.com/2011/08/11/better-web-font-loading-with-javascript/

The short version is: commercial CDNs either don't offer a way to do this on the server at scale, or will do it but only as a custom deployment that can be very expensive at virtually any scale. Google can do it server-side for their Web Fonts API because they're Google, and have their own, very robust CDN infrastructure. We initially did it client side because we were on a startup's budget, however using JavaScript we're also able to target browser edge cases (such as the IE rendering mode) that aren't reliably detectable with just a UA string.

I practically guarantee you that if responsive images don't have native content negotiation in the client, adding a JS-based solution is one of the first things I'd need in order to recommend using responsive images at scale.

We need to capture a use case and requirement(s) based on the above.

@ShaneHudson

For this Use Case it might be worth referencing RFC 2295 which provides a technical overview of content negotiation.

@marcoscaceres

@ShaneHudson thanks for the link. We should probably also check out HTTPBis as it's more updated.

@nwtn nwtn was assigned
@marcoscaceres

@ShaneHudson so, after thinking about it, I think it would be safer just to point to the HTTP spec.

@marcoscaceres

FYI, I've rewritten one of the requirements:

The solution MUST NOT require server-side processing or HTTP content negotiation.

I'll start on the use case now.

@nathanaeljones

Also, I'd like to bring up the eBooks/ePub use case. EPUB closely tracks (X)HTML development, and has historically avoided 'extending' HTML markup specifications, although it has been freer with CSS.

By nature, an offline HTML file/archive or EPUB book doesn't support HTTP negotiation. Most offline readers do not support javascript either.

However, they are both in a challenging position when it comes to images, as readers often only support one image format (until recently, only PNG was supported by many readers), and many variants are needed to support the variety of screen types (e-ink, LCD) and resolutions (Think Kindle/Nook on iPad 3 vs Android).

I know I'm describing two different use cases here (offline HTML and EPUB), but they do share a lot. A good solution to responsive images will be of great benefit to both situations.

@igrigorik
  • RFC 2295 has one major flaw: it imposes a huge latency penalty by requiring an extra list response in the workflow.
  • User-Agent techniques are a dead-end, and cannot adapt to dynamic use cases
  • Client-side techniques have similar penalty (or worse) as RFC 2295

A work-in-progress, Client-Hints: https://docs.google.com/document/d/1xCtGvPbvVLacg45MWdAlLBnuWa7sJM1cEk1lI6nv--c/edit#

I would relax the language for "MUST NOT require server-side processing". The server is the origin, and given more information, it can do intelligent things and work well with intermediate caches. Granted, the Client-Hints proposal is independent of, and not limited to responsive images use cases.

@ddemaree
@marcoscaceres

Agreed, the wording could probably be a little better (and agree with @ddemaree). I'm open to suggestions.

@igrigorik

@ddemaree I want to dispel the myth that only Google or Adobe would be able to do server-side adaption. Just like srcset defines a well-known "2x" filename, nothing stops us from defining multiple filenames (via a convention, a configuration flag, or similar), for other variables: name-lw.jpeg vs. name-hw.jpeg for low-bandwidth, vs high-bandwidth. (may not be the best example, but you get the point). These files can be created at build / design time, and live on the server side-by-side. Nothing new here.

Re, language: right, I'm with you guys. I just want to make sure that when people read these use cases, they don't rule out the server-side adaption entirely. If the server supports it - great. But I agree that it can't be a required component.

Perhaps something like: The solution MUST NOT require server-side processing, but server-side adaptation may be used where available through or [HTTP11] content negotiation, or similar techniques.

@Wilto
Owner

The solution MUST NOT require server-side processing, but server-side adaptation may be used where available through or [HTTP11] content negotiation, or similar techniques.

That seems fair to me. Would it make sense to expand it to something like:

The solution MUST NOT require server-side processing or HTTP content negotiation, but SHOULD NOT preclude the use of server-side adaptation and content negotiation.

Spec-writing is way outside of my wheelhouse; I’m not sure if the “SHOULD NOT” is appropriate here—just throwing that one out there.

@marcoscaceres

How about:

The solution MUST NOT require server-side processing to work. However, if required, server-side adaptation can still be done through [HTTP11] content negotiation or similar techniques.

@Wilto, pro tip: in spec land, you can't ever have a MUST followed by a SHOULD.

@Wilto
Owner

See that? I learned something today.

The solution MUST NOT require server-side processing to work. However, if required, server-side adaptation can still be done through [HTTP11] content negotiation or similar techniques.

Sold.

@marcoscaceres

Ok, added it to the spec. Have not committed it yet.

@ddemaree, sorry I have not actually been able to articulate a full use case section around this yet. We were prioritising the launch of responsiveimages.org and preparing for presenting at TPAC next week :( However, it might be sufficient to just have the requirement and not a full use case description: content negotiation is understood to be a cataclysmic failure.

@igrigorik

@marcoscaceres @Wilto looks good, thanks for the quick turnaround!

@MattWilcox
Collaborator

I am very glad to see the Content Negotiation in like this. And very glad to learn about Client Hints, those are what I've been wanting for a long while :)

@marcoscaceres

As we added the requirement, I'm closing this bug. Please reopen if you think we need to add anything else.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.