Error 504 - Gateway Timeout with page width at 100%

[nicozanf]

Hi, I've got a "504 - Gateway Timeout error" before asking for the filename to export the page to. This is totally reproducible if I use a Template Style Settings --> "The width of the full site (can be any length unit: %, px, em, ...)" = 100% instead of the default 75em. As a workaround, I use a big value in em (175em) instead of the 100%. The same problem occurs with huge em values like 750em. I'm using RH 8, Apache with PHP 7 and the latest application versions.

[dipohl]

I experience the same error under Rocky Linux 8, PHP 7 and PHP 8.0 in recent patch level and current dokuwiki version 'Release 2022-07-31a "Igor"'. I use the standard template with default values!

[Klap-in]

I cannot yet reproduce this (ubuntu/development version dokuwiki - using 'dokuwiki' template/last version plugin/php8 and php7.4) Tested by first setting the width of my wiki to 100% (also 750em tried), next exporting the wiki:syntax page as pdf. In all cases no "504 - Gateway Timeout error".

Did you use any pdf-template for the dw2pdf plugin? Further, I have not yet idea what I could ask to discover how I could reproduce this, as we have already two reports I expect there is something going on here.

[Klap-in]

Could you also test with the wiki:syntax page? does it matter what is on the page, i guess it is independent from your description? with almost empty page it is also reproduce-able for you?

[nicozanf]

Yes, I can totally reproduce it with an almost empty page and also the wiki:syntax page. I'm not using any pdf-template for the dw2pdf plugin, only standard settings. Note that after changing page's width you need to close and reopend the browser in order to be sure to load the changed page and not a cached one.

[dipohl]

I get the error on all pages (independent how much or what sort of content the page has) also on the wiki:syntax page. Today I tested on a third dokuwiki instance which is residing on a server in the public internet. This has the same configuration and dokuwiki version and a similiar set of extensions. The error is not existent there. The other instances, where I see the error, reside on two servers in LAN behind the firewall. They have access to the internet only thru a proxy server. I assume the cause for the problem likely there (internet access / network configuration)?

[dipohl]

I looked around a bit and found pdf export files - that are ready to view - in the cache directory, although the Gateway Timeout had arised.. e.g. cache/a/a3184c78afee57edb457607b0db9301c.dw2.pdf

[Klap-in]

Is there a QR code in your pdf, if I remember it right, this needs the internet… Might be that there is something timing out? Making the QR size config setting empty will disable it.

[dipohl]

Bingo! With deactivated QR code it works :-D

[Klap-in]

For me it does not explains the observation that the page width has an influence. Might be that it slows down the rendering as well and combined with not reaching the qr code generator, the total delay is too much?

I guess most people will update the template for their purposes, and remove the qr code. The provided PDF-template is just to demonstrate the possibilities.

[dipohl]

May be, we have two issues here.. In my case I didn't choose a special page width but used the default values for that (as written before). As we didn't find a solution nor identified the concrete problem but only found a workaround I am not so happy with closing this ticket.

[Klap-in]

@dipohl, could you explain what the remaining issue(s) is?

• There was mention of different page widths. I have test this, and I cannot yet reproduce it. Can someone confirm that with internet connection this is still an issue, in that case more info is needed for me to reproduce it.
• There was mentioned that wikis on LAN do not work, while on WAN it is fine. You confirm that disabling the qr code fixes this on the wikis that are on LAN. For me this is logic, because in the default pdf-template there is a qr code. This qr code is generated by doing a call to https://quickchart.io/ for generating the qr code. So with no internet connection to the outside it does not get a response and times out. So disabling is not a workaround, but a logic solution. If you need local qr code generation, it can be added with e.g. https://github.com/mpdf/qrcode ). A pull request is welcome for replacing this ;-)

[dipohl]

@dipohl, could you explain what the remaining issue(s) is?

I use your plugin for many years and it worked also on the servers behind the firewall. May be the failure comes from changed network configuration on our side but may be it is caused by the internet service that you use. I will try to find out that asap. Will report my findings here. Thanks for your support!

[dipohl]

I will try to find out that asap. Will report my findings here.

I have not yet found the exact reason for the failure but have made some observations that I want to share with you. It seems that the call of https://quickchart.io/ is working but that the existence of the QR-Code breaks something in function WriteHTML (in /lib/plugins/dw2pdf/vendor/mpdf/mpdf/src/Mpdf.php).

[dipohl]

It seems that the call of https://quickchart.io/ is working but that the existence of the QR-Code breaks something in function WriteHTML (in /lib/plugins/dw2pdf/vendor/mpdf/mpdf/src/Mpdf.php).

As I found out now I was mistaken therewith ^^

From the webservers log: [Fri Oct 14 20:46:35.769508 2022] [proxy_fcgi:error] [pid 1572:tid 140254631618304] (70007)The timeout specified has expired: [client xx.xx.xx.xx:62792] AH01075: Error dispatching request to : (polling)

By increasing the timout limits in Apache configuration to a very high value the PDF generation now comes to a regular (though ugly late..) finish. It would be fine if someone implements a local QR code generation ;-) I will disable QR codes now on the servers with the long delay..

From my view the closed ticket is ok now :-)

[Klap-in]

Could you create an ticket for that feature request?