no picture on first page load

upon reload, the picture shows up

Hi Florian,
require_course_login($course, true, $cm); impose a nice auto-login for Guests.
A first branch on the logic above towards a redirect is the forcelogin setting, Force users to login: could you check if that setting is disabled in your Moodle instance and if on could you make a test setting it off?

If the "off test" will fail, can you log into your Moodle instance checking that the authentication is kept while browsing different Moodle pages?

As you can understand, we should find the exact scenario to allow replicating the issue otherwise it could be difficult to investigate why under some network circumstances, the delivery of an image of a lesson fails just the first time, due to an HTTP 303 redirect (Moodle requiring login).

Besides, does your issue appear even on desktop browsing the site using your phone connection? This could confirm the link between a particular network (usually browsing is provided by means of a Proxy) and your issue.

TIA,
Matteo

Hi Matteo,
I checked that forcelogin setting. It's set to off. If it's useful: guest-settings autologinguests = Off; guestloginbutton = Hide.

I understand that replicating this might be tricky. So I try to help/describe the problem as good as I can.
On a desktop computer, the authentication is kept throughout the entire site. No problem so far. The authentication is even kept on mobile connections (as far as simple browsing through courses goes), but just not for files which are requested by pluginfile.php.

And yes, the problem even appears if I tether my mobile connection to a desktop computer. It's the same experience, the page loads fine, except for the image.

screenshot-3.jpg from Chrome Dev Tools: using a direct connection via wifi on a desktop computer, the browser sends the session cookie, the image gets loaded as expected.

screenshot-4.jpg from Chrome Dev Tools: using a mobile connection via the carrier proxy on a desktop computer, the browser does not send the session cookie, the browser gets redirected to the login page.

That's interesting: so 1.1.1.n/bmi could be the root for all.
I'm just reading around the net about it and someone - http://stackoverflow.com/questions/4113268/how-to-stop-javascript-injection-from-vodafone-proxy - suggest the adoption of Cache-Control: no-transform to avoid stuff to accelerate the connection.

If you want to test it, please patch your lib/filelib.php as shown below:

diff --git a/lib/filelib.php b/lib/filelib.php

index dbbd782..1c35db6 100644

--- a/lib/filelib.php

+++ b/lib/filelib.php

@@ -2126,11 +2126,11 @@ function send_temp_file($path, $filename, $pathisstring=false) {

     header('Content-Disposition: attachment; filename="'.$filename.'"');

     if (strpos($CFG->wwwroot, 'https://') === 0) { //https sites - watch out for IE! KB812935 and KB316431

-        header('Cache-Control: max-age=10');

+        header('Cache-Control: max-age=10, no-transform');

         header('Expires: '. gmdate('D, d M Y H:i:s', 0) .' GMT');

         header('Pragma: ');

     } else { //normal http - prevent caching at all cost

-        header('Cache-Control: private, must-revalidate, pre-check=0, post-check=0, max-age=0');

+        header('Cache-Control: private, must-revalidate, pre-check=0, post-check=0, max-age=0, no-transform');

         header('Expires: '. gmdate('D, d M Y H:i:s', 0) .' GMT');

         header('Pragma: no-cache');

     }

In the mean time I'll investigate a bit more root reasons and possible solutions.

TIA,
Matteo

Hi Florian,
any chance for you to test the above no-transform hack?

Hi Matteo,

thanks for your patience and the help so far. I had no time over the past few weeks and the holiday season allowed me to postpone this issue.

Today I've done some testing again and found out your solution helps a bit. However, some page elements are still linked via the Proxy-URL 1.1.1.x/MYSITE and some are not. Because we want the whole site to not being transformed or changed in any way I took your advice (no-transform) and applied it to lib/weblib.php in the send_headers function, with the result of a perfectly unchanged and unharmed response...

As the code comment suggests, caching is in any way undesired, so I thought the additional no-transform complies with this. These are my changes:

--- weblib.bak.php      2013-09-06 14:00:08.000000000 +0200

+++ weblib.php  2013-09-06 14:00:15.000000000 +0200

@@ -1899,12 +1899,12 @@

     if ($cacheable) {

         // Allow caching on "back" (but not on normal clicks)

-        @header('Cache-Control: private, pre-check=0, post-check=0, max-age=0');

+        @header('Cache-Control: private, pre-check=0, post-check=0, max-age=0, no-transform');

         @header('Pragma: no-cache');

         @header('Expires: ');

     } else {

         // Do everything we can to always prevent clients and proxies caching

-        @header('Cache-Control: no-store, no-cache, must-revalidate');

+        @header('Cache-Control: no-store, no-cache, must-revalidate, no-transform');

         @header('Cache-Control: post-check=0, pre-check=0', false);

         @header('Pragma: no-cache');

         @header('Expires: Mon, 20 Aug 1969 09:23:00 GMT');

Added the no-transform directive - Refs.: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.5 - in any place where at least an image is supposed to be delivered. Note: at this time it seems that the only media type being the target of conversions is an image media type though there's no limit to what media types could be transformed.
Reading at http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1 about private confirms that there is no relation between no-trasform - whose aim is to reduce the amount of traffic before saving cache space - and private so no-transform has been added even when private has been already added.

Hi Petr,
based on your past work with the private directive, would you like to peer review these PRs about no-transform?

TIA,
Matteo

Added a missing no-transform directive in theme/image.php.

please do not assign me as reviewer to any issue, I do it myself when I know I will review it, thanks

nice detective work, +1 for this change, thanks for the report and fix

Great work guys! I've integrated this to master, 26, 25 & 24

(I find it sort of offensive that a no-transform header even exists )

Tested the header, 'no-transform' was present.

cheers

David built a framework for behat
At first just to test this and that
10000+ steps written
Sounds like we're all smitten
And David should be smiling at that

Thanks for reporting, patching, and testing this issue. It has been released upstream along with 64 others today.

Just for reference, here is a nice explanation about the Mobile ISP image recompression: http://calendar.perfplanet.com/2013/mobile-isp-image-recompression/. Not found at the time of proposing this fix.

Our school district was having an issue with staff uploading large-resolution images. Most modern cameras and phones now create 5MB+ images. Our solution was to use Google's mod_pagespeed to automatically resize the image to match the img tag's width= height= values. This reduced the load on the server, reduced load on the Internet connection, and made browsers load the page much faster. Tested on firefox, chrome, iOS, Android; desktops, phones and tablets.

I had to remove this "no-transform" Cache option in lib/filelib.php lib/weblib.php theme/image.php and theme/yui_image.php to get mod_pagespeed to work properly. I also had to add some code to filelib.php for (send_file & send_stored_file) to detect image mime type to send the proper cache settings.

1) Find the code that sets the mime to x-forcedownload:

    $mimetype     = ($forcedownload and !$isFF ) ? 'application/x-forcedownload' :

                         ($stored_file->get_mimetype() ? $stored_file->get_mimetype() : mimeinfo('type', $filename));

2) Insert the following code just above it:

    // Check for image and adjust to allow caching and resizing by mod_pagepseed

    $image_mime = array("image/gif","image/jpeg","image/png");

    $mimetype = mimeinfo('type', $filename);

    $isImage = in_array($mimetype, $image_mime );

    if ($isImage) {

      $forcedownload = false;

      $lifetime = $CFG->filelifetime;

    } 

Hi Dean,
why didn't you configure mod_pagespeed to ignore no-transform? Here is the relevant conf from the docs, https://developers.google.com/speed/pagespeed/module/configuration:

By default, PageSpeed does not rewrite resources that have Cache-Control: no-transform set in the Response Header. This is true for all types of resources, such as JavaScript, images, CSS etc. By respecting Cache-Control: no-transform headers, PageSpeed cannot optimize resources that could otherwise be rewritten.

To optimize resources irrespective of Cache-Control: no-transform headers, you must add

Apache:

ModPagespeedDisableRewriteOnNoTransform off

Nginx:

pagespeed DisableRewriteOnNoTransform off;

to your configuration file.

Please note that PageSpeed will always respect Cache-Control: no-transform headers on HTML files irrespective of the setting. And also, PageSpeed will always retain the Cache-Control: no-transform headers on the resource irrespective of the setting so that the downstream cache control mechanisms do not get affected.

With regards to the second core hack I do not understand why you should not honor Moodle forcing files to be downloaded: this is e.g. the enforced policy when you add files to a post in a forum since you cannot trust them by default. Maybe, your use case could be proposed as an improvement for the security policies in the next Moodle version, to let an administrator to configure whether images could be viewed inline even if attached in a forum post.

HTH,
Matteo

I tried the no-transform override first and it did not work.

  ModPagespeedDisableRewriteOnNoTransform off

End-users are too often not resizing the images before uploading them. I needed an easy automated solution and mod-pagespeed works well.