Generated RSS feed has malformed URLs when using HTTPS about kiramoji

[Flameborn]

Thanks. It seems that wakautils.pl in this case is not imported by kiramoji.pl, at least when generating the feed.

Since wakautils.pl does not use 99.99% of the config variables, I've opted to add a $protocol variable instead. By default, it's set as http, but changing it to https should generate proper links now.

Please reopen if it still doesn't work.

[Flameborn]

This might depend on the used web server.

Our instance uses https, and the RSS feed does not include a port number.

Links are generated using http in the feed, but the server redirects to the https protocol instead. This is possibly something that needs to be looked into in the future.

What steps did you take to produce these malformed links?

[dewheel]

The environment is as follows:

Ubuntu 22.04 LTS
Apache v2.4.52
perl v5.34.0
Kiramoji v3.2

Spin up an instance of Kiramoji in the above environment in message mode and configure Apache2 to redirect all traffic to https, that should reproduce the issue. You're running Caddy in your instance, correct?

For the instance I'm having trouble with Apache2 is configured to redirect all http request to https with mod_rewrite, which may have caused the issue to surface. Aside from a hacky edit of wakautils.pl to resolve the issue (as I've done), I believe tweaking mod_rewrite to redirect http://example.com:443 URLs to https://example.com may also resolve the issue in the interim.

[Flameborn]

Thanks for posting your environment.

I think the problem is that Apache provides a few things as environment variables that Caddy doesn't, which is likely the reason why it works here.

By default, Caddy tries to redirect http connections to https, and while Apache does the same, it also provides, I believe, a port number as an environment variable, which throws browsers off.

Adding native HTTPS support is something I would need to research, ideally with LetsEncrypt.

For now, I could add a protocol variable to the configuration file, defaulting to HTTP, which would take over the hardcoded protocol values for $absolute_self and $absolute_path. This would still add the port number to the URL, which we could ignore if set to 80 or 443. I'm not sure if this is the best solution though, as I would personally do this via the used web server. But then again, getting rid of hard-coded values is always a good idea.

I'm definitely open to ideas ☺️

[dewheel]

Thanks for posting your environment.

Of course, please let me know if you require any more info regarding my implementation.

A protocol variable would be a good way to resolve this, that or determining the protocol programmatically if possible (well beyond my depth). I would also be partial to dropping $port entirely from $absolute_self and $absolute_path, but this would cause issues for site owners who use non-standard ports (I think they still exist). On the other hand, if Caddy doesn’t provide a port number at all and still works as intended then maybe $port can be removed after all. A hardcoded HTTP link without a declared port would still work on any site that redirects HTTP traffic to HTTPS.

[Flameborn]

I've added a PROTOCOL config variable. The port number, if 443, should not be part of the generated URLs as well, similarly to how port 80 behaves. You can find this at https://github.com/Flameborn/Kiramoji/tree/FixMalformedURLs

Could you please test these changes and see if they fix the issue for you?

In config.pl, uncomment line 68, which should set the protocol to https for the generated URLs.

[dewheel]

I just tested your changes and unfortunately that did not resolve the issue. Links in the RSS fee are now formatted as follows (note the missing protocol):

<link>://example.com/kiramoji/index.html</link>
<link>://example.com/kiramoji/kiramoji.pl/12345/</link>

Does wakautils.pl reference the configuration files? It appears the PROTOCOL variable it's referencing is empty. Furthermore I didn't see the following at the top of wakautils.pl

BEGIN { require 'config.pl'; }
BEGIN { require 'config_defaults.pl'; }

[Flameborn]

Thanks for giving this a go. I believe the culprit was a dollar sign, which absolutely shows my mastery of Perl ☺️ It should work now, since I believe *wakautils.pl* is called from *kiramoji.pl*. Would you mind trying again please?

…

On 2022. Jul 25., at 15:38, Junk ***@***.***> wrote: I just tested your changes and unfortunately that did not resolve the issue. Links in the RSS fee are now formatted as follows (note the missing protocol): <link>://example.com/kiramoji/index.html</link> <link>://example.com/kiramoji/kiramoji.pl/12345/</link> Does wakautils.pl reference the configuration files? It appears the PROTOCOL variable it's referencing is empty. Furthermore I didn't see the following at the top of wakautils.pl BEGIN { require 'config.pl'; } BEGIN { require 'config_defaults.pl'; } — Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHLD4EPQ6E4FFO3HXM6EE3VV2KGDANCNFSM54MNV6BA>. You are receiving this because you commented.

[dewheel]

I gave it another go, unfortunately that got us a little farther off the mark, here's how the RSS is now formatted:

<link>PROTOCOL://example.com/kiramoji/index.html</link>

[dewheel]

Worked as expected, thank you for your assistance!

[Flameborn]

You’re most welcome. I’m glad it worked ☺️

…

On 2022. Jul 26., at 14:08, Junk ***@***.***> wrote: Worked as expected, thank you for your assistance! — Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHLD4AQ7H2AHKKBY7XZ67TVV7IK7ANCNFSM54MNV6BA>. You are receiving this because you modified the open/close state.