With a switchover to a 64bit platform (+ other some other changes) from our hosting provider, grav stopped the possibility to download files.

The seen error is: ERR_EMPTY_RESPONSE

I do not know how to solve this problem.
The hosting provider tells me: They found an error saying: crbug/1173575, non-JS module files deprecated

Grav is in Version 1.7.34 installed.

You can see the Error at page home | Grav
go to history and klick on books or proceedings to download

Regards and Thanks for Help.

This doesn’t look like a usual download link. Do you use some plugin?


When a link in a page points to a file in the folder of the page, like <a href="/typography/x.pdf">Download</a>, Grav is not involved. The webserver itself will happily download the file, unless…
- The file doesn’t exist
- File permission issues
- .htaccess issues
- other issues beyond my imagination…


Above statement is incorrect. Grav’s involvement in fetching files depends on the url being used:

  • Url points to the file’s path: /user/pages/02.typography/myimage.png
    => Grav is bypassed
    These urls are generated with adding images in Markdown using ![My Image](myimage.jpg) or using Twigs {{ (|first).html() }}

  • Url points to a route: /typography/myimage.png
    => Grav is needed to parse the url


A weird thing is:

  • Both files are in the same folder, but they produce different errors…

Maybe, there is a collision with cache when cache folder has also been copied? Try bin/grav cache and also clear the cache in the browser

Also try the following:

  • Create a fresh install of Grav 1.7.34

  • Copy file 17_2019_KT-Kolloquium_Tagungsband.pdf into folder /user/pages/02.typography/ and add link <a href="/typography/17_2019_KT-Kolloquium_Tagungsband.pdf">Download</a> to file /user/pages/02.typography/

    If the download fails, your probably have one of those “unless” issues in which case I have no more suggestions…


Dear pamtbaau,

support of the weboster first said, i have to clear the cache.
So i did in the admin interface a “clear all caches”.
This did not resolve the problem.

Next was to deactivate the caching on the server.
So i had to add to modify htaccess and for php the user.ini
htaccess → Header always set Cache-Control: s-maxage=0
user.ini → opcache.enable=0

This also did not resolve the problem.

Is there a guidance how to completely deactivate caching?


Next was to deactivate the caching on the server.
So i had to add to modify htaccess and for php the user.ini
htaccess → Header always set Cache-Control: s-maxage=0
user.ini → opcache.enable=0

Why would you want to do that?

Maybe a misunderstanding of my suggestion to “clear the cache in the browser”. I meant to make sure the browser is forced to send a request to the server. For that you can use:

  1. Windows and Linux browsers: CTRL + F5.
  2. Apple Safari: SHIFT + Reload toolbar button.
  3. Chrome and Firefox for Mac: CMD + SHIFT + R.
  • Or (in Chrome at least), you can set option “Disable cache (while DevTools is open)”

It would probably not make a difference, it is just a matter of routinely making sure the browser is not causing any side effects.

To prevent further miscommunication: What is your level of expertise if I may ask?

dear @pamtbaau

these were the suggestions of the support of the hosting provider.

To avoid a problem with the cache of the browser i used firefox and microsoft edge.
I also pressed reload many times. No effect.

My level of expertise … not an expert, but i try my best.

@Stephan, Well, the suggestions by your provider doesn’t seem logical to me with respect to this issue…

To narrow down the problem area, try the fresh install of Grav suggestion. I would like to add an extra step.

  • Add an image into folder /user/pages/012.typography/ and add the following to file /user/pages/02.typography/ ![My Image](your-image.jpg)

See what happens…

1 Like

dear @pamtbaau

thank you, i will try tomorrow when i have more time

your question about the pictures i can already answer:
at the site editorial board (Editorial Board | Grav) there are already pictures in the page … and, they do not have the problem of not loading.

please have in mind, that we have put all other pdf’s at this site in an extra folder outside grav. we linked them like because we needed a quick solution. but this solution is not how grav should work

@Stephan, Grav shouldn’t have issues with symlinks. Has your webserver been configured to follow symlinks?

For example:

<Directory /var/www/html>
     Options Indexes FollowSymLinks
     AllowOverride All
     Require all granted

This reminded me of a page I made about six months ago, so I checked the links and the source templates. Sometimes I make comments in the source about unexpected kludges but this time I didn’t unfortunately. However I do remember the link URLs weren’t what I expected (or preferred really).

So if you look at the paths, they show the full path in /user including Grav folder prefixes. (Note that a new version of this page not yet launched moves these files out of modular folders, but they still show /user/... and prefixes.)

I don’t think you specify whether you are coding your link via page markdown or in a template. I used a template pulling filenames from frontmatter. For what it’s worth, here is a simpification of the template that serves these URLs (current modular page version). It may be useful:

{% if page.header.abstracts is defined %}
  {% if page.header.abstracts.file is defined -%}
    <a href="{{[page.header.abstracts.file].url }}" class="image clear" type="application/pdf">
  {%- endif -%}
{% endif %}

So I’m letting Grav derive the URL here.

I also thought of the possibility that multilingual paths are screwing up your media URLs, but simply removing the language path did not help. (My limited experience with multilingual pages makes me think paths can be buggy.)

Hope some of that is helpful.

dear @hughbris

i have to confess that i have not everything understood you wrote,
but i found some interessting things of the path where pictures and douments are linked
At your mentioned site it is all like

At my site i found differences like this

Pictures are linked like yours, but the “not working” pdfs are completely different.

Could somebody explain?

By the Way.
I did a test with another hosting provider.
I created an test account, copied a backup to the account and everything worked fine, inluding the linked pdfs…
So, i see the possibility that some settings at Grav and/or Server could solve the problem.

Sorry it probably was confusing! I think your host’s setting might be the problem here as others suggested. One of the problems with shared/managed hosts is that you often lose control over this kind of configuration. Good luck!

dear @pamtbaau

according to my question regarding your hint of the symlinks i got this answer from the support of the hosting provider:
symlinks are already set correctly

furthermore they told me to test these .htaccess rules:

Header set Accept-Ranges none
RequestHeader unset Range

I did so, without any effect.

dear @pamtbaau
i did also this you instructed me:

I am not happy, the result is the same …
have a look at
I put the links at the end of the typography page.
The first link is done as you described, the second one is done within grav.

Screenshot 2022-07-14 100826

I’ve updated my earlier reply about Grav’s involvement when fetching files. I overlooked the type of Url being used.

@Stephan, Hm… Is the file still symlinked, or located in the folder of the page? If still symlinked, try also copying the file into /user/pages/02.typography

Try using the following links in the page

<a href="/user/pages/02.typography/17_2019_KT-Kolloquium_Tagungsband.pdf">Downlaod</a>
<a href="/symlinked/path/to//17_2019_KT-Kolloquium_Tagungsband.pdf">Downlaod</a>

And also
Above link bypasses Grav (see my update).

The link <a href="/typography/17_2019_KT-Kolloquium_Tagungsband.pdf">Download</a> does require the involvement of Grav.

Even if the link to the path of the pdf does work, which hints to an issue with Grav, I’m still inclined thinking is not an issue with Grav, since using the same site on different servers yields different results…

dear @pamtbaau and @hughbris

many thanks for your support

i just got a message from the support of the hosting provider
they added RequestHeader unset Range to the .htaccess and the download for pdfs works now as expected.