403 error

Hi Wonko - unfortuantely the news is pretty straightforward here - it sounds like either your server is misconfigured, or the RPC URL in your blog settings got changed?

This is something you can test pretty easily. If you open up the Weblog details (just double-click the blog item in the drawer), you'll find the RPC URL in that setup dialog. Copy and paste that into your browser to test whether the server gives you the same error when you manually load it outside of MarsEdit.

If that seems to work but the error still occurs in MarsEdit, can you open the RPC Console (from the Widnow menu in MarsEdit) and then try to refresh again?  Send the debugging log from that window to support@red-sweater.com and I'll take a look!

Daniel

Yes, please do sen the RPC Console file.  It sounds like the URL itself is working if it was able to tell you it wants a POST. I'll investigate further!

Daniel

Dennis: yes, the extent to which MarsEdit "makes a remote connection" is to provide HTTP POST requests over port 80 to your server (unless it's an HTTPS connection).

I know some hosts explicitly filter xmlrpc.php, so it was a good idea of yours to test against test.php. I'm not sure how they would filter against this unless they outright forbid all HTTP POST activity. If they won't relent on this policy, it frankly sounds pretty restrictive.

I would ask them to compare their policy against other hosting services which obviously allow such functionality. It's especially annoying that it sounds like they changed the policy on you after having things work previously

It might be worth sending them a copy of the RPC Console (Window -> RPC Console) when you try to refresh your blog. Then they can confirm or deny that they don't allow that specific type of HTTP activity.

Daniel

Wonko: the plot definitely thickens. I should have tried this from the start, but for some reason it didn't occur to me because I don't have your password and such. But there's nothing to keep me setting up your blog on my MarsEdit, with the *wrong* password.  I did this, and instead of the expected "bad password" reply, I got the same 403 error you are seeing!

The funny thing is the same request from curl (a command line tool I use for network debugging) seems to WORK.  So I definitely think there's a nuance here and it's something MarsEdit is doing. Sorry to make you run around in circles so many times before I figured this out.

I will be updating ASAP with more information as I find it.

Daniel

OK - I am sorry for the rapid-fire messages here - I think you can ignore the other ones for now I'll leave them there for posterity.

I narrowed the problem down to a rather technical detail. I think you should share this information with your host and see what they say. As far as I can tell there is a configuration problem no your host because they are behaving drastically differently depending on the "Content-Type" of the request:

When MarsEdit or any other remote editor connects to your WordPress installation, it communicates with HTTP POST requests. In every case the contents of the HTTP messages are XML data, so the "Content-Type: text/xml" header is passed along with the request.  But your server seems committed to only returning the expected value if the Content-Type is set to "application/x-www-form-urlencoded", a typical value for *forms* that are posted, e.g. from a web page.

I don't believe there's anything MarsEdit can do to alleviate this. I think the server has to be accommodating of "Content-Type: text/xml" requests. Can you please run this by your server's support again and see if they have any second thoughts about whether there have been changes?

Daniel

Daniel:

The host came up with the following workaround that works like a charm.

Create a .htaccess file.
Add the following:

<IfModule mod_security.c>
   SecFilterEngine Off
   SecFilterScanPOST Off
</IfModule>

Save and upload the .htaccess file to the directory with the Wordpress files.

All is well now.

Thanks for all your time on this.

Wonko, Daniel:

The .htaccess solution worked for me as well. Thanks for your help!

Hi LameName - sorry about the spam filtering problem. Maybe I should turn that filter off now that I have the silly captcha (math) at registration.

Also sorry you've been having bad luck getting the server working with MarsEdit. I'm sure we can get to the bottom of it.

Thanks for posting the RPC log - it's very helpful. It does look a lot like a simple (heh "simple" is a relative term) HTTP server configuration issue. If you take the URL that MarsEdit is trying to access, your RPC URL: http://www.duncanmoran.me.uk/blog/xmlrpc.php, and paste it into a plain browser like Safari, you'll see the same "Not Allowed" error message. That's not *necessarily* a problem but on the vast majority of servers, the file is "GET"-able from a regular browser, even if the script just says "You shouldn't be getting this. For instance, compare with my blog's URL: http://www.red-sweater.com/blog/xmlrpc.php

If you can get in touch with your server admins and tell them that the xmlrpc.php file needs to be publicly accessible for POST requests by the web server, then they should be able to help you to get things in working order.

Let me know if I can be any more assistance.

Daniel

My server (Pair.com) has a similar policy, though they're able to "green light" a particular account for xmlrpc.php usage. At least we have a good explanation!

I don't think renaming it will cause problems, but you will have to remember to rename again whenever you update WordPress. Actually a good trick might be to use a symbolic link. From the shell account, assuming you have one:

ln -s xmlrpc.php MyXMLPost.php

That way the renamed version will always point at the real one.