I set force_ssl to true by accident and then when reverting to false and running server I get the following error:
ERROR bad Request-Line
WEBrick 1.3.1
INFO ruby 1.9.3 (2012-02-16) [x86_64-darwin11.4.0]
WEBrick::HTTPServer#start: pid=472 port=3000
ERROR bad Request-Line `\x16\x03\x01\x00?\x01\x00\x00?\x03\x02P?Mf\x00??C?'.
How can I fix this?
When I hit http url on local host it redirects to https and gives me this error:
SSL connection error
Unable to make a secure connection to the server. This may be a problem with the server, or it may be requiring a client authentication certificate that you don't have.
Error 107 (net::ERR_SSL_PROTOCOL_ERROR): SSL protocol error.
Answer can be found here: How to use deactivate Webrick's SSL
you can fix it by clearing the browser cookies and it works again. It seems the authentication information is saved in the cookie and keeps reverting our requests to HTTPS but does not authenticate correctly so you get that error.
Maybe you can try:
1) stop rails server
2) rake tmp:clear on the command line
Then start again and see if the problem persists.
UPDATE:
Maybe you can try to clean any cache content / history content on your browser too.
I usually end up using a different explorer, i.e.: Safari, Firefox, etc. As clearing the cookies do not solve the problem for me (while using Chrome at least)
Related
This has been a problem for myself and my colleagues who have also tried this for quite some time (we keep revisiting the issue to try and fix) whereby the process of getting the packages for a flutter app fails. It works perfectly from my home pc but in work it does not.
Running flutter pub get from my cli returns pub get failed (-10737418819). If I append -v to flutter pub get I get much more information which describes the HTTP get it attempts to make which is:
https://pub.dartlang.org/api/packages/cupertino_icons
with an accept header of 'application/vnd.pub.v2+json'
If I then use a tool such as Postman to send a Http Get with this information, it fails and reports that it could be down to:
Self-signed SSL certificates are being blocked:
Fix this by turning off 'SSL certificate verification' in Settings > General
So I turn this setting off and it works as expected, returning JSON data about the cupertino packages. I think the fix to my problem has something to do with SSL certificate verification but I don't know where to start. Does anyone have any idea?
Generally the Issue is from server side as the Website does not has SSL Certificate and you are trying to access with "https".
use the Same URL we "HTTP" it will work
I had this working properly and all of a sudden during a restart stopped working and I can't get to the bottom of what happened.
Basically, vue/node (dev) mode is using http but the ajax uses https to the server.
Server responds with all headers including Access-Control-Request-Origin and I can see json data response from the server in the firefox dev tools
But for some reason it throws an Error: Network Error alert. Inspecting in dev tools I find
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://r.roller.lan/workstations?session_token=2de63puojmt3ubkfp94c3ohm45. (Reason: CORS header “Access-Control-Allow-Origin” does not match “https://devv.roller.lan:8080”)
I am making request from http://devv.roller.lan:8080 and somewhere in the chain gets translated to https:// which doesn't match?
Thanks
Everything works as expected after I added highlighted portion from the Nginx Reverse Proxy article Koshux referenced to the nginx conf.
A lot of people have ask this question but it was 2 month ago with another gitlab version,
I'm using gitlab 5.2 in a fresh debian 7.0 serveur
everything looks Okay on the website but when I run /home/git/gitlab-shell/bin/check I've got this error :
Check GitLab API access: FAILED. code: 302
Check directories and files:
/home/git/repositories: OK
/home/git/.ssh/authorized_keys: OK:
I'm running on a custum ssh port but I'm able to connect.
When pushing I've got this error:
git push -vu origin master
Pushing to ssh://git#apps.ndd.fr:2232/Users/test.git
fatal: The remote end hung up unexpectedly
Thanks for your answers!
I've just got the same error and go look onto the code.
The thing I've found the gitlab_net module going for answer at #{host}/check (gitlab-shell/lib/gitlab_net.rb)
host method is defined as "#{config.gitlab_url}/api/v3/internal", and at the same time config.gitlab_url defined in ./gitlab-shell/config.yml "Should end with a slash" (c) So my web server just returns 302 on a request to remove double slashes.
FYI: That fail is about API and not about web service. So it's non-critical in many cases anyway.
I think it's a minor bug in code and there is a close issue to this: https://github.com/gitlabhq/gitlabhq/issues/3483
Im building my first Rails app server on a Ubuntu server machine. I came to the point where i am testing a simple add located on the server. When I hit the root page, default rails message
"Welcome on board, You’re riding Ruby on Rails!"
Thats good i suspect. But when I hit server/todos i just get this error message
"We're sorry, but something went wrong."
How can I see full error message? I am completely new to Apache and Passenger. I suspect I could get full messages if i run from the server but there is no GUI or browser installed.
Ok found out this was all connected to the Rails app and not a Apache or Passenger setting.
# environments/production.rb
config.consider_all_requests_local = true
So my Rails (3.2.1) app was working fine on Heroku. Then I set config.force_ssl = true in my production config file, upon opening the file, I now got the "SSL is not enabled" error. I thought Heroku allows you to piggyback their SSL certs, but it is not working for me.
What I've tried:
using heroku addons:add piggyback_ssl (fails, as the add-on is now standard..)
validating my account (shouldn't be necessary, but I tried it anyway)
changing my config.force_ssl = false, but my app still tries to use SSL...
I may a bit late, but the reason that your browser still redirects you to https even if you have that option turned off in Rails has to do with the "Strict-Transport-Security" header (HSTS).
Try installing the Piggyback SSL addon as follows:
heroku addons:add ssl:piggyback
Once that's installed and your app has been restarted, it should be accessible at both of the following addresses:
http://your-app.heroku.com
https://your-app.heroku.com
Looks like you might have caught Heroku in the middle of a rollout. As of a few weeks ago, Piggyback SSL is now enabled for all users/apps by default. If you're still seeing the "SSL is not enabled" error, you should contact Support.
http://devcenter.heroku.com/changelog/10