4

I am running a LAMP stack on CentOS with Drupal 6 and the latest Services module. Over HTTP the REST server I have running works fine and behaves as expected.

When I installed an SSL certificate I forced all port 80 traffic to 443 (SSL). This worked fine for Drupal but has caused the REST server to return no data. Naturally I have removed the force SSL and allowed both HTTP and HTTPS for the time being.

I am testing via Fiddler, which when used to access the endpoint over HTTP, returns the expected data. Testing over HTTPS I receive no data. Do I need to make a configuration change to the REST server (i.e. I missed something in the documentation).

Thanks in advance for any support!

EDIT

To show the difference clearly, I made an anonymous POST request to the end point (it could have been a GET request the end point has no real methods but thus returns a message to let us know it is still there). I get the success message that the end point is running over HTTP. HTTPS however returns no data at all. I have shown this in the images below.

HTTP

enter image description here

HTTPS

Request via HTTPS

.conf SSL Rule These lines are no longer in use but are here to illustrate what I was doing.

#RewriteCond %{SERVER_PORT} !^443$
#RewriteRule ^(.*)$  https://%{SERVER_NAME}%{REQUEST_URI} [L,R]

Edit2:

I found something related in my Drupal Forums search http://drupal.org/node/704308

Graham Smith
  • 25,627
  • 10
  • 46
  • 69
  • Could you post the full request and response headers? It's definitely a problem with the server and not something like e.g. the client not being able to validate the SSL cert? – Eli Mar 23 '12 at 20:28
  • I have added some extra info above. Please do note that I have commented out the lines that caused a redirection to help force a secure connection. These are not the cause of my woes it seems. – Graham Smith Mar 23 '12 at 21:43

2 Answers2

2

It's hard to say without more details about how you force HTTPS, but I presume this uses a redirection.

If this is the case, this is not very useful and is more likely to give you a false sense of security. If the client is configured to use HTTP, even if the server forces it to HTTPS via a redirection, the initial request is still made over plain HTTP (before the redirection).

If your client is still configured to use an http:// URL (and you're relying on the redirection to get it to use HTTPS), the redirected POST requests will lose their body (and are likely to be a GET, in fact), see this answer. As a result, your requests wouldn't work at all as you'd expect.

You should check that your web-service client is using https:// URLs and that whatever subsequence URLs you get from the web-service to itself also use https:// (or that they are relative and that the client is able to stay on HTTPS).

EDIT:

One way to find out whether you get an issue with a redirection is to turn off plain HTTP completely (not even using redirections), for example by commenting out Listen 80 in your Apache Httpd configuration. If this gets worse (e.g. you get messages saying you can't connect), that's a stronger indication the issue has to do with an incorrect redirect set up (as described above).

Community
  • 1
  • 1
Bruno
  • 119,590
  • 31
  • 270
  • 376
  • I have added an edit above to show how I was forcing SSL. This is now commented out so I am no longer forcing traffic over HTTPS. I am going through the drupal module code to see if there is any reference to the site's default url. There is a lot to go through though. – Graham Smith Mar 23 '12 at 21:34
  • I think it is also worth noting that from my example above: that the original request can be either POST/GET and I will have the same response (as the end point doesn't have any methods so it effectively says "hello I am here" as its response). So even if the POST becomes a GET I should still receive some data even if it is an error - right? – Graham Smith Mar 23 '12 at 21:42
1

What you describe sounds suspiciously like one of these two:

  1. Something is not listening on the port it should be listening on. If Apache forwarded a request to a broken socket then I'd expect that it would return a 500 error code, so the goal is to try to figure out where the message is going, what port your application is listening on, whether your REST application even supports the HTTPS handshake, and so on.

  2. Apache is not interpreting your requests on port 443 the way that it interprets requests on port 80. This sounds a little more suspicious because you say that Drupal works over 443 and yet the stuff which you've written doesn't generate headers at all -- if Apache were forwarding your API requests to your Drupal application you would expect to at least see headers, 404s, etc when it fails to properly interpret API requests.

Without more information I'm not sure we can help.

CR Drost
  • 9,637
  • 1
  • 25
  • 36
  • To be clear I had not setup my virtual hosts correctly. I was trying to use name based rather than an IP based virtual host. I.E rather than (I only have a single IP for this server). – Graham Smith Mar 30 '12 at 17:46