log shows "Nested HTTP request to generate..."

This is fine. The module needs to do this to be able to serve e.g. ImageCache files from the CDN: to be able to serve them from the CDN, it needs to generate them first. That's all what's happening.

The number of entries that say that should diminish over time, as all your ImageCache files will have been generated by then.

Seeing as this reads like the same question, I'll re-open it rather than open a new issue.

Similarly - I've just set up with AWS-CF as the CDN, with Origin Pull. (CSS-aggregation is enabled in the performance settings.)

I have a node that has an attached file which is an image. I use a private file system for the site. It is therefore retrieved using a url /system/files/foo.jpg. The node then displays that image in an img tag.

Without far-future expiration set, the src attribute in that img tag is correctly re-written as http://cdn-base-uri/system/files/foo.jpg. But when I enable far-future expiration, it remains as http://www.my-site-uri/system/files/foo.jpg. The watchdog contains 4 entries, each of which inform me about the Nested HTTP request.

It makes no difference whether the source for the node references the image using /system/files/foo.jpg, or the fully-qualified http://www.example.com/system/files/foo.jpg.

Is this a result of the private file system? Or do I need to change some other setting somewhere?

Curiously - I don't know if it's related: When I go to disable far-future expiration, and save the configuration, I get a warning at the top of the screen: Potentially problematic domains: abcdeabcdeabcde.cloudfront.net uses the same web server as this Drupal site. That's patently untrue, so I ignore it, but I'm mystified as to why it thinks that's the same server.

It'd be great if you could give it a quick try *without* the private file system (i.e. switch from public to private).

From the FAQ in the README:

Q: Is the CDN module compatible with Drupal's "private files" functionality?
A: Yes. The CDN module won't break private files, they will continue to work
   the same way. However, it cannot serve private files from a CDN. Not every
   CDN supports protected/secured/authenticated file access, and those that do
   each have their own way of doing this (there is no standard). So private
   files will continue to be served by Drupal, which may or may not be
   acceptable for your use case.

OK - I can confirm that the public / private file system is the issue here. Not sure why private files are served over the CDN when far-future isn't enabled, but I created a new field on that node type that would store a public attachment, and that URL was rewritten by the CDN module.

Thinking about it, that makes perfect sense - CDNs cannot be relied upon to handle file-access, so that is the safer course of action.

Nearly "works as designed".

But before changing the status to close the issue: Surely there shouldn't be 4 errors in the Watchdog for every attempt to load a page that has a privately-stored image attachment?

There should be 2 per private file, IIRC. IIRC, CDN module tries to generate missing files (it is assumed that this are generated automatically, e.g. ImageCache) once, then gives it another chance, then bails.

Does that answer your question? :)

That makes sense, thank you.

In that case, IMHO, when handling private files that should not be put through a CDN, the message to the watchdog should not be that there has been a nested http request (with severity "critical"), but (if anything) a simple notice that logs that the private item listed below could not be rewriten to the CDN.

Well, then I'd have to detect private files, which the CDN modules doesn't do yet. So I'm not going to do that, since private files are explicitly not supported. You're the first to ever report this problem, too :)
I'll gladly accept a patch that detects this though! It shouldn't be logged, it should be detected in hook_requirements(). That would then be picked up automatically on the CDN module's config pages. You can do that over at #1793652: hook_requirements() should check if the private file system being used :)

I'll join that issue...

Just adding a note if someone else comes across these error in their logs. If you have a private file you'll get this error. The CDN module has an OTHER section where you can wild card some files or paths.

Here is a sample: system/files/prdoc/*.docx

Now it's black listed.

I recently faced this.

1. NO private files. Serving only public files.
2. Does not diminish over time as mentioned above.

So this is not related to private file serving. But it does seems to be related to 1) Far Future setting and 2) Amazon CF CDN.

https://www.drupal.org/node/1949832

I am seeing this error, too, also using AWS CloudFront. It is marked in the log with severity of "Critical" but the top of this thread suggests it is a warning. In my case this is related to AdvAgg aggregates:

Nested HTTP request to generate sites/default/advagg/advagg_js/js__y5p-UBtvjJfiftoDwlAe7_EZYCx4p_xTN31Spj2c54A__4w2RKvQO-TjTUD7WT1a2HI9_bW_LIt9FRhaK3lius_4__3VBaL40a2_VVlyb38mUENWKjhs--SYL84oGZEw1czj0.js: failure (URL: https://projectbotticelli.com/sites/default/advagg/advagg_js/js__y5p-UBtvjJfiftoDwlAe7_EZYCx4p_xTN31Spj2c54A__4w2RKvQO-TjTUD7WT1a2HI9_bW_LIt9FRhaK3lius_4__3VBaL40a2_VVlyb38mUENWKjhs--SYL84oGZEw1czj0.js, time: 1513752057).

I would be grateful for any hints. Many thanks.

Apologies for adding to this thread. I have now reported it as a new issue #2931948: Exclude AdvAgg aggregates from CDN module's Far Future functionality.