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

Already on GitHub? Sign in to your account

Content negotiation and CDNs #10

Closed
marcoscaceres opened this Issue Oct 16, 2012 · 16 comments

Comments

Projects
None yet
8 participants
Owner

marcoscaceres commented Oct 16, 2012

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.

Contributor

ShaneHudson commented Oct 18, 2012

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

Owner

marcoscaceres commented Oct 18, 2012

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

@ghost ghost assigned nwtn Oct 18, 2012

Owner

marcoscaceres commented Oct 18, 2012

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

Owner

marcoscaceres commented Oct 18, 2012

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.

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.

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

The key word here is "require". Maybe the language can be clearer in this respect, but the point here is that a solution that requires server-side processing without the possibility of client-side negotiation is significantly less useful for people who are less handy on the server side than you or I, or who lack the budget to scale a server-side solution the way Google or Adobe can.

I don't think this language precludes using the server where appropriate, as an enhancement over the baseline spec.

On Oct 25, 2012, at 1:43 PM, Ilya Grigorik notifications@github.com wrote:

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.


Reply to this email directly or view it on GitHub.

Owner

marcoscaceres commented Oct 25, 2012

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

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

Owner

Wilto commented Oct 25, 2012

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.

Owner

marcoscaceres commented Oct 25, 2012

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.

Owner

Wilto commented Oct 25, 2012

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.

Owner

marcoscaceres commented Oct 25, 2012

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.

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

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 :)

Owner

marcoscaceres commented Dec 2, 2012

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