I am getting this error when I am starting my server
[2016-01-06 18:57:00] ERROR bad Request-Line `\x16\x03\x01\x00�\x01\x00\x00�\x03\x03B0�c�ezc�*�[S'.
[2016-01-06 18:57:00] ERROR bad URI `�\x00�7���\x04^\b��\x02W'���U��1lH|�A�t\x00\x00\x1E�+�/\x00��\x14�\x13�'.
[2016-01-06 18:57:00] ERROR bad Request-Line `\x16\x03\x01\x00�\x01\x00\x00�\x03\x02�\x05\x01\x1D��~�-\x01Lω\x01���L"��\f� ����[�\x0F�\x00\x00\x14�'.
[2016-01-06 18:57:00] ERROR bad Request-Line `\x16\x03\x01\x00�\x01\x00\x00�\x03\x01
\x0E�|�s��(�9��4V:��*\f'\fh^衜&���-�\x00\x00\x14�'.
I disabled config.force_ssl = false and I also uninstalled thin... But every time when I open localhost:3000, it is automatically opening the HTTPS version https://localhost:3000/.
There are two possible reasons:
The https may be in the browser cache. Clear the browser cache, close the browser and retry.
As I explained in this article, the force_ssl configuration also sets the HSTS header. This header tells the browser that any subsequent request must for that domain be sent to HTTPS instead of HTTP (until the previously set expiration which by default is 1 year). You will have to also remove that domain from the browser HTTP list. How you delete the domain depends on the specific browser. Here's an example with Chrome and Firefox.
Related
Using the angular 2 debug server, I proxy requests to the real server using proxy.config.js. It seems that the ng2-signalr library does not respect the proxy configuration, and will attempt requests to whatever was defined as url in the IConnectionOptions used.
for the following request:
GET
localhost:4200/signalr/negotiate?clientProtocol=2.1&user=client&connectionData=%5B%7B%22name%22%3A%22compilationhub%22%7D%5D&_=1557816148076
the following error is produced:
Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, https
What would be the best course of action?
I got this working by adding the signalr route to proxy.config.js and setting the url property of my IConnectionOptions to location.origin. This setup bypasses the default route of /signalr so that a double forward slash route is not used.
I installed TFS 2017 to be accessible on both, HTTP (port 8080, default settings) and HTTPS. Now I removed HTTP binding form the IIS and reapplied the Public URL (via Administration Console -> Change Public URL).
Most of the TFS application tier works normally (as it uses relative addressing). However, build extensions somehow want to get their icons from HTTP (port 8080). See screenshot. When I noticed this, I first checked the HTML/JS source and I found that _vssPageContext variable still holds some URLs pointing to old HTTP configuration.
Has anyone solved that mistery or has any idea what to do?
EDIT: Later I re-enabled the HTTP bindings in IIS just to make the TFS work and I get a lot of warnings and errors due to HTTP / HTTPS mixup (I access TFS via HTTPS, however some content is still accessed via HTTP):
Mixed Content: The page at
'https://xxxx.xxxxx.xxxx/tfs/TFSDefault/Project/_build/definitionEditor?definitionId=113&_a=simple-process'
was loaded over HTTPS, but requested an insecure image
'http://xxxx.xxxxx.xxxx:8080/tfs/TFSDefault/_apis/distributedtask/tasks/9fcb05af-0ffe-4687-99f2-99821aad927e/0.1.1305/icon'.
This content should also be served over HTTPS.
WebSocket connection to
'ws://xxxx.xxxxx.xxxx:8080/tfs/signalr/connect?transport=webSockets&clientProtocol=1.5&contextToken=412c3608-de3b-4dab-a00d-bf5c13728d97&connectionToken=OoSymcl1qzWg%2BrHB9pzSBpb%2BdHVywo7NNUWN5xMx3Z51p9ZdZQ14wvoQKXqxB%2Bvo66eTap4iUdlqzHR1hJNUf%2By8oFUaudlkCbQIZjHQhLBHsEWtcLdfLlL7MAevl4h0My1yQA%3D%3D&connectionData=%5B%7B%22name%22%3A%22builddetailhub%22%7D%5D&tid=7'
failed: HTTP Authentication failed; no valid credentials available.
This is an issue related to the default endpoint of TFS being initially set as http, which all the elements are then defaulting their requests to, rather than relying on the initial request you are making in the browser. so you end up with a javascript element attempting to connect to the server via http and get a cross content issue.
Here is a really good article that covers the issues you are probably facing and how to fix them to use https: https://hybriddbablog.com/2017/12/16/changing-tfs-to-use-https-update-your-agent-settings-too/
I have to caveat that I havent done this yet, we actually went back in favour of running http until we moved to the next version of TFS, but from my experience of TFS, the steps look sound.
This problem appears specific to routing for JRuby ajax requests. My page sends an ajax GET which works fine in rails development mode. When moved to tomcat via warbler, the request is generated correctly, but tomcat responds with a 404 error.
In other words, the line in routes.rb get '/sector/method' is sufficient that http://localhost:3000/sector/method is processed by Webrick, but if I change the port to 8080 (tomcat) I get a HTTP status 404 The requested resource (/sector/method) is not available.
Apparently tomcat needs to be told it is OK to process the GET even though there is no corresponding file to be found. Right? Fixes?
Thanks.
Are you sure your request point to correct address? if application works, there is no way that GETs does not. Please try to put the request directly into your browser and check...
There is a nice option to config for the Rails app:
config.force_ssl = true
However it seems that just putting that to true doesn't get the HTTPS connections working. Even more - after trying (and failing) to connect to https://localhost:3000 with Chrome, I've set this option to false, and Chrome still tries to open https, even if I write http.
So, couple of questions:
--How to force Chrome not to try https anymore?
--What is the proper way of enabling SSL on my Rails app?
Update: The app is run on Heroku, and it seems that https is supported there automagically. Can I test SSL also locally? Like when running rails server?
First, I should say that I haven't tried this, but there are mainly two possibly reasons for Chrome still using HTTPS:
Using HTTP Strict Transport Security headers: if the server sets them, the client (supporting HSTS, like Chrome) is meant to stick to HTTPS for all subsequent requests to that host.
Permanent redirects. If the initial redirect you got was using "301 Moved Permanently" (and not 302 for example) to make the redirection,(*) the browser is meant to remember it ("The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs").
A likely solution to this would be to clear the cache in your browser.
(*) This question seems to indicate this is the case for Ruby on Rails with this config).
I had the same issue. What I did is using an ssl enforcer gem which adds a middleware that handles ssl and redirects. It has a strict option which enforces the configured protocols.
in your Gemfile add:
gem 'rack-ssl-enforcer'
in production.rb add:
config.middleware.use Rack::SslEnforcer, only: %r{your_regex_condition}, strict: true
This will force the requested pages to be secured and the rest to be non secured. It disables the HSTS header which is problematic in chrome (redirect caching issue).
You can also expire the cache for all cleints (if it already exist) to make sure you'll not get infinite redirect:
config.middleware.use Rack::SslEnforcer, only: %r{your_regex_condition}, :hsts => { :expires => 1, :subdomains => false }
also remove the ssl enforcement in production.rb (otherwise it might conflict with this middleware):
config.force_ssl = false
Let's see what happened once you updated your config file with:
config.force_ssl = true
This has caused Rack SSL Middleware to be loaded as the first middleware. As you can see in the code, Rack SSL sets an HSTS header by adding this line to the headers :
Strict-Transport-Security
It tells supported browsers such as Chrome to use HTTPS only to access your website.
So once you set back :
config.force_ssl = false
Chrome will still uses HTTPS to access your website and causes an error.
To solve this problem, you need to empty the HSTS cache. You can to that by going to the following url in your chrome browser :
chrome://net-internals/#hsts
Open your Chrome Developer Tools when you're at localhost: Then you can right click the refresh button ↻ and select "Empty cache and hard reload".
This error might also happens to you, if you start your server in the production environment, where HSTS is enabled.
Chrome redirects you to https://localhost:3000/ and says "SSL connection error".
Two clients complains on HTTP Error 400 from Mozilla Firefox 3.6.9. This happens when they open any link - both mvc application and also any static images, which are hosted on Classic application pool without any code.
Exact error message is HTTP Error 400. The request is badly formed
No errors in windows log and application error log. Proxy in browser is set to off.
Other browsers works fine for them.
Any ideas about what could cause such behavior?
For now, i can see only one option - ask them to install Firebug, but this is not really user friendly.
For some reason, cookies was corrupted and this was leading to HTTP 400 error.
After user cleaned cookies for this website he was able to get page.
I still need to investigate what exactly went wrong and find source of this problem but it is clear that I need to review all places where I do cookie creation.