HTTPS is redirected to HTTP
pheyvaer opened this issue · comments
When doing a query to an LDF server with https, the fragments are requested via http instead of https.
When the client is created, a request with https is done (as shown in the console), but once fragments are requested http is used. Chrome and Firefox complain about this if the initial page that is using the LDF client is being served using https with the error about 'mixed content'.
From where are you querying?
Browsers can complain if you are doing requests from a http webpage to a https webpage, so you may want to use a https-enabled webclient like this one: https://query.linkedsoftwaredependencies.org/
Command-line should work fine in any case.
I'm querying from a Webpage that is being served via https, but I say to the client to query the server with https, so why does it happen via http then?
Which version of the ldf-client are using at LSD then?
Yes, command line indeed works.
Then that won't be the problem...
One other possible cause might the an incorrectly configured baseURL. Does it contain https?
You can check this by manually checking the next page url's when doing a curl -H 'Accept: text/turtle' request.
(Also, if you ever tested it on the non-https endpoint, make sure to properly clean your cache)
LSD is using the jQuery Widget of this version: LinkedDataFragments/jQuery-Widget.js@c64c54d
OK, that narrows down the problem to the server, instead of the client I think.
The config of the server has https in the baseurl, but the next page url's use http.
Can you show me your config file?
For reference: adding "protocol": "http" didn't solve the issue.
@RubenVerborgh Any idea on what else could cause this?
Weird, never had this issue. Can't be the client idd, because it just follows links. Is there a redirect involved? Could also be NGINX messing things up...
Nginx redirects http to https, but that would not explains why the RDF returned by the LDF server has links without https, right?
Perhaps NGINX is not forwarding all required information.
@pheyvaer Could you try adding these lines to your location block inside your NGINX site config?
proxy_set_header Host $http_host;
proxy_pass_header Server;
That information is already there.
Ok, then I'm out of ideas again for the moment :/
it does right? NGINX translates the protocol, but the server doesn't know that, so it keeps creating http links?
What does NGINX do exactly? Input: HTTPS, Output HTTP?
location / {
proxy_pass http://127.0.0.1:3000$request_uri;
proxy_set_header Host $http_host;
proxy_pass_header Server;
}
if ($scheme != "https") {
return 301 https://$host$request_uri;
}
So the requests are send to the ldf server running on port 3000 and if http is used, go for https.
I tried setting the proxy_pass to https, but that doesn't work, because I don't have ssl set up on the ldf server (should that also happen there?).
That looks ok.
On the LDF server you don't have to setup SSL, only make sure your baseURL includes https and "protocol": "http" is present.
I think we bumped on an edge case here. The HTTPS support in the LDF Server does not take HTTPS proxies into account.
Two solutions would be:
- Let NGINX rewrite the controls in the response to HTTPS (not really a solution, inefficient)
- add a proxy setting to the server which only does the URL construction, but not activate the SSL layer (because NGINX does that)
This edge case should've been fixed in LinkedDataFragments/Server.js@7fbdae8 I think.
We do exactly the same thing as @pheyvaer on http://data.linkeddatafragments.org/ and https://fragments.linkedsoftwaredependencies.org/
Not exactly. The problem is this:
https://github.com/LinkedDataFragments/Server.js/blob/master/lib/LinkedDataFragmentsServer.js#L17
and
So maybe this is the scenario that occurs
- Client requests
https://x/fragment - NGINX turns it into
http://x/fragment - LDF server receives
http://x/fragmentas requestUrl - LDF server constructs controls from the requestUrl:
http://y/fragment - NGINX proxies body with
http://y/fragmentinside, but underhttps
Is the scenario exactly the same with the other setups?
OK, so the problem with the https in the results of the LDF server seems to be fixed. I used baseUrl instead of baseURL, so the URL was not read at all... 😫 Maybe we could add some information to the output when the server is started that states which baseURL, if any, is used?
I'm gonna have a look at the client specific code to see if any issues are still present there, and I'll report back.
I guess we should include that in https://github.com/LinkedDataFragments/Server.js/blob/master/bin/ldf-server#L180
Also, it's correctly in the documentation :)
Anyways, for what the client is concerned, this issue is closed.
I'll include this in the feature-lsd branch, as I'm making changes related to that anyways.