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.