[Plugin: podPress] Server returned HTTP Error 403: Forbidden

Andrew,

After changing the slug name, both URLs(testfeed3) will validate. They also show all my blog entries when I un-check the “Include only…” option.

This and the fact that at least one of the podcast Feed URLs is working makes me think that the procedures which add the Feeds and populate them with posts are working correctly in podPress 8.8.9.

What happens with the /?feed=podcast Feed when you un-check the “Include only…” option? Does it work while the non-default Permalink scheme is active and option is un-checked?

My .htaccess file does contain the instructions you have listed.

That is good. But are there also other instructions in this file?

If un-checking the “Include only…” option of the podcast Feed makes no difference, the problem is probably more a problem of the rewrite rules or other redirection techniques. Maybe it helps if you set back all the Permlink rules by following these steps:
– deactivate the podcast Feed
– deactivate podPress
– set the Permalinks back to the default scheme
– save the Permalink settings
– activate podPress
– activate the podcast Feed again
Does the /?feed=podcast Feed work again after this step?
– change the Permalink setting to a non-default scheme
Does the /feed/podcast and the /?feed=podcast URL work after this step?

If this is not helping then it might be worth it to make test with 8.8.6.3.

Regards,
Tim

Tim,

Because I’m not sure what I’m exactly looking for in my .htaccess file, I only noticed two other things that look like the instructions you showed before. They are these:

[.htaccess moderated as per the Forum Rules. Please use the pastebin]

Does this help? If not, I’m going to have to downgrade to 8.8.6.3 because the other method you described does not work either.

BTW, after following your orders and testing, I’ve been setting my permalink structure to a non-default. iTunes has been using the /feed/podcast to access my media.

The WP forum filter has filtered what you have found in your .htaccess file before I could see it. Please, use pastebin (or a comparable service: https://en.wikipedia.org/wiki/Comparison_of_pastebins ).

Or maybe you post only the lines which are different here in this thread (in case these two other things are only two lines. Maybe do not mark them as code).
I have uploaded podPress 8.8.9.1 beta 1 to the repository. That version includes some control points. If you install this version which is the current Development Version and a little helper plugin which I have written ( https://undeuxoutrois.de/downloads/aaaprintphpnotices_v02.zip ) then it might be possible to determine where and when the problem occurs during a call of the podcast Feed.
If you can activate the helper plugin which has the title “Print PHP notices” without problems then this plugin will create a log file in its folder with the name wp-content/plugins/aaaprintphpnotices/printphpnotices_log.dat
After you have activated the helper plugin, click on this feed URL https://theonlypodcast.com/?feed=podcast. After that deactivate the helper plugin again. Because it would log not only the calls to this podcast Feed URL.
Each call in the log file will start with a line of Number signs (hash tags) # .
The next line would be “podPress class init – before adding the feeds”.
And if the call is success full then last line would be “podPress_do_dyn_podcast_feed”.
What I would like know what last line is if you call that not working feed URL. Or whether there are log entries in that file after you chave called the Feed.
If the helper plugin produces an error during the activation then it is most likely beacuse the plugin is not able create the log file in the folder of the plugin.
If you can not activate the helper plugin, maybe downgrade to 8.8.6.3 for a test.
But I see no point in doing that for more than a test. As you have said the /feed/podcast URL is registered in the iTunes Store and that URL is working in 8.8.9 and the Feed Button plugin uses always the current Feed URL (scheme). So, it is possible to subscribe to your podcast via both ways.

If the problem exists also when you downgrade to 8.8.6.3 then you may ask your hosting provider for help.

Regards,
Tim

Here is the pastebin of what I tried to post in my last comment, in case it makes any difference.

The plugin helper .dat file only shows this:

[11.01.2011 – 18:20:07] ‘plugin installation’

even after I click the podcast URL.

Should I still test with 8.8.6.3, even though I didn’t receive an error, or should I just contact my host?

No. Do not downgrade. It is one (or two) lines in you .htaccess file.

I’m not an .htaccess-expert. But i have put all the lines from the pastebin in to the .htaccess file of my blog and could reproduce the behaviour we could observe in your blog. /?feed=podcast was not working while /feed/podcast was working.

I have also tried to disable some of the lines to find out which one is responsible. I have not tested all. But if you put a hash tag (#) in front of the lines which include this command RewriteRule ^(.*)$ - [F,L] then the /?feed=podcast URL seems to work regardless of the current Permalink scheme.

But I would recommend to ask the one who has put all these RewriteRules and RewriteConds into your file for their meaning and necessity. Maybe if you disable these two lines something else will not work right (Although, I think that it seems to be not right, that this line is twice in the file).
If you switch on a non-default Permalink scheme WordPress writes automatically all the rules which are necessary for the blog into this file and it removes them when you switch back to the default scheme. But WP does obviously not overwrite rules which are already in this file. Sometimes other rules might be necessary. Most of the WordPress rewrite rules in the .htaccess file redirecting requests like https://www.example.com/feed/podcast to the PHP files or scripts which create the feed. If these rules are not in place this request would only work if there would be a folder /feed/podcast/ and would lead to this folder.

Thank you for your reports!

Regards,
Tim

(Don’t forget to deactivate the “Print PHP Notices” plugin.)

@toptm – I’m glad ntm figured out the issue. Assuming you are looking at the .htaccess file in your web root dir, my guess is that those directives were put in place by GoDaddy. They are probably an attempt to secure your site against bots and spammers.

RewriteRule ^(.*)$ - [F,L]
seems to be a rule that forbids *everything* and will return a 403 error for all requests. I would guess that it is followed by lines that allow only “acceptable” requests.

In any case this is an issue that you should take up with your hosting provider. Contact GoDaddy support and hopefully they can advise you on how to modify your .htacess file.

-Ray

Tim,

Finally, we have a solution!

@ray

Thank you for “translating” what RewriteRule ^(.*)$ - [F,L] means.

@both of you,

This may all lead back to another plugin I have installed. I had added the Bulletproof Security plugin after receiving a ‘possible hack attempt’ scare. This plugin affects my .htaccess file and could very well be the reason why that Rewriterule exists.

Thank you, both of you, very much.

I’m sorry I caused so much confusion and loss of time.

-Andrew

Andrew,
don’t be sorry. It was important to find out whether it is a bug of podPress or something else. If it would have been a podPress bug then I would have tried to fix it.
Sometimes I don’t discover bugs myself or only if someone else reports a problem.
Thanks again for the report.

-Tim

Tim,

This is how the process is going with the Bulletproof Security plugin designer:

Hi Andrew,
Forget my previous suggestion. I took a look at podPress and it is doing something other than what I had expected. The question mark (?) in the query string is seen as an illegal external request. I am currently testing podPress and will add it to the Compatibilty Testing page tomorrow in pending status. Thanks.

Thought I would give you an update.

-Andrew

Andrew,

thanks for the update.
Is this a discussion in a public forum? Or an email exchange?

-Tim

Tim,

The conversation started as a comment on his website, but has developed into an email conversation. This was his latest entry:

Nope disregard this. I found a way to test this without having to configure
everything and have been able to recreate the error and also to have it work
correctly so I am now putting together the correct htaccess code that will
work. I just needed to understand exactly what was happening and now I do.
Will have a fix pretty soon.

As for the the “Nope, disregard this…”, it’s because he sent me a previous email with code I should try to input in my .htaccess file.