Ask your WordPress questions! Pay money and get answers fast! Comodo Trusted Site Seal
Official PayPal Seal

wp_remote_get and internal server error 500, but tinyurl works WordPress


I have a plugin which fetches an ics file using the wordpress function wp_remote_get.
wp_remote_get is supposed to try various ways (http, fopen, curl etc)

For a few remote servers producing ics files, when trying to fetch the ics file the function returns:

<title>500 Internal Server Error</title>
<h1>Internal Server Error</h1>
<p>The server encountered an internal error or
misconfiguration and was unable to complete
your request.</p>... etc

Now googling for answers indicates that the problem is probably on the generating server. That maybe url file access is disabled or it is a permissions error.

HOWEVER The same urls will work if
1) mapped to using tinyurl (I reverse decoded it, and it does map to same url)
2) subscribed to in google calendar, local pc calendar

Example (from;Op=iCalSubscribe&#038;AddIns=1&#038;Includes=1&#038;x=1
Returns 500 server error
Works (returns ics file):

I did also find notes that sometimes the error is not detailed enough. eg: with godaddy windows servers. . (Not that that helps with understanding what is going!)

1. why does a tinyurl work when the original does not?
2. is it something to do with the server doing the request/fetch? (ie host server allows tinyurl, and tinyurl allows fetching server?....)
3. is there something else that the plugin could/should do too to get around these situations ?

Answers (3)


Gabriel Reguly answers:

Hi Anna-marie Redpath,

It is really puzzling.

I could reproduce the issue where the remote server works fine for any browser, i.e. servers an .ics file, and via my site ( using wp_remote_get - with either 'curl', 'streams', 'fsockopen' ) it always returns an HTML file instead of the .ics file.

However your test server has the same behavior, so I suspect is something to do with the query string.

I'll have another try later today.

Anna-marie Redpath comments:

Dear Gabriel /all,

I think lawrence was on the right track. I coded a simple (non wp ) curl script and that worked... so now to figure out what curl option wp is setting that causes the problem... learning more about curl....

Also for the record:
applying urlencode resulted in 'Invalid url' being returned.

(also while testing, found some calendar providers sending ics content without a text/calendar contenttype, but that is another story....)


Benjamin Goldberg answers:

This isn't an answer but here's some info for anyone still interested in this.

1) The URL that I provided to Anmari was a trial subscription and may become invalid. The new URL is:

2) From what Anmari posted, the original http request fails completely, and is followed by a curl attempt. It's the curl request which produces the symptoms that I described in [[LINK href=""]][[/LINK]]. So the lost parameters are probably a completely separate issue from whatever is causing the http request to fail in the first place.

3) I contacted Brown Bear software but they don't know what the problem is either. Any testing outside of the wp environment seems to produce a proper ical file.

Anna-marie Redpath comments:

Hi all,

when inside wp, must pass url to curl or wp_remote_get with

html_entity_decode ($url)


Denzel Chia answers:


Your internal server error is fixed.;Op=iCalSubscribe&#038;AddIns=1&#038;Includes=1&#038;x=1

Works for me.

Please see attached screenshot.

You probably needs a more stable web hosting service.
You can not prevent server internal error, it happens to me a few times due to hosting server hardware malfunction.

You can check with your hosting service provider, regarding what happened to your server during this period of 500 internal error.


Anna-marie Redpath comments:

Hi Denzel,
quick reply, but not exactly.

So in situations like these

Dropping the url into the browser works -> you get an ics file back.
Ditto with google calendar subscription/import to the url.


when same url is accesses via wp_remote_get, one either gets a server error, or more common now that i think of it, one gets the HTML of a page from the site (not the ics file). Actually I think the server error happened if one drops the url into the shortcode in visual mode (with encoded & - DUH) and the "html instead of ics" is returned when one uses the wordpress html mode (ie the url is entered correctly with no &amp;)

I have debug code in my plugin. If one does 'view source' on this page
the plugin dumps the result it gets from the wp_remote_get... and it is html not ics code for the example given.

Compare to this page fetching 2 icsfiles from other servers. Public google calendars are also fine.

Also note the ics servers are not mine, I have no control over them - they simply have calendar files that users of my plugin wish to access to display on their websites. (All I have control over is my plugin and my test site.)

So basically I'd like to be able to tell users of my plugin what is going on when
a) they try to use something else's ics file in the plugin and it does not work.
b) maybe someone else has a problem (I've not yet had this complaint) when someone tries to access the ics feed that my plugin produces.

Denzel Chia comments:


I don't really know what happened.

But as a general rule, you need to url encode the request url before doing any http request.
taken a quick look at amr-import-ical.php where you used wp_remote_get, you did not use urlencode.
May doing it will help. Url encode can also "prevent" losing query variables, which is what your forum post mentions.