-
Dmytro Zaporozhets (DZ) authoredFix external issue tracker hook/test for HTTPS URLs If HTTPS was used for the 'project_url' of an external issue tracker, an error was raised because a HTTP connection was established to the default HTTPS port. The code has been corrected and simplified by using HTTParty. Additionally, the request now is made directly to the 'project_url' instead of the extracted root path. ## The bug is reproducible on gitlab.com 1. Set up a new external issue service (I used Redmine) 2. Set the project URL to 'http://example.com/redmine/projects/x' and click on 'Test settings' => Ok 3. Now set the URL to 'https://example.com/redmine/projects/x' and test it again => 500 ## What is actually happening? Web servers behave differently when a non-SSL connection is established to a SSL port: - Nginx / Apache 2.4: Status code 400 - Apache 2.2: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">... (no status code line is sent) - example.com: Empty response, no status code line ## Relevant log entries ``` 2015-06-04T11:10:47.972Z 16785 TID-exfks WARN: {"retry"=>true, "queue"=>"project_web_hook", "class"=>"ProjectServiceWorker", "args"=>[...], "error_message"=>"wrong status line: \"<!DOCTYPE HTML PUBLIC \\\"-//IETF//DTD HTML 2.0//EN\\\">\"", "error_class"=>"Net::HTTPBadResponse", ...} 2015-06-04T11:10:47.972Z 16785 TID-exfks WARN: wrong status line: "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">" 2015-06-04T11:10:47.972Z 16785 TID-exfks WARN: /usr/lib/ruby/2.1.0/net/http/response.rb:41:in `read_status_line' [...] /home/git/gitlab-7.11.4/app/models/project_services/issue_tracker_service.rb:88:in `execute' /home/git/gitlab-7.11.4/app/workers/project_service_worker.rb:8:in `perform' [...] ``` See merge request !767
6c7131b4Dmytro Zaporozhets (DZ) authoredFix external issue tracker hook/test for HTTPS URLs If HTTPS was used for the 'project_url' of an external issue tracker, an error was raised because a HTTP connection was established to the default HTTPS port. The code has been corrected and simplified by using HTTParty. Additionally, the request now is made directly to the 'project_url' instead of the extracted root path. ## The bug is reproducible on gitlab.com 1. Set up a new external issue service (I used Redmine) 2. Set the project URL to 'http://example.com/redmine/projects/x' and click on 'Test settings' => Ok 3. Now set the URL to 'https://example.com/redmine/projects/x' and test it again => 500 ## What is actually happening? Web servers behave differently when a non-SSL connection is established to a SSL port: - Nginx / Apache 2.4: Status code 400 - Apache 2.2: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">... (no status code line is sent) - example.com: Empty response, no status code line ## Relevant log entries ``` 2015-06-04T11:10:47.972Z 16785 TID-exfks WARN: {"retry"=>true, "queue"=>"project_web_hook", "class"=>"ProjectServiceWorker", "args"=>[...], "error_message"=>"wrong status line: \"<!DOCTYPE HTML PUBLIC \\\"-//IETF//DTD HTML 2.0//EN\\\">\"", "error_class"=>"Net::HTTPBadResponse", ...} 2015-06-04T11:10:47.972Z 16785 TID-exfks WARN: wrong status line: "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">" 2015-06-04T11:10:47.972Z 16785 TID-exfks WARN: /usr/lib/ruby/2.1.0/net/http/response.rb:41:in `read_status_line' [...] /home/git/gitlab-7.11.4/app/models/project_services/issue_tracker_service.rb:88:in `execute' /home/git/gitlab-7.11.4/app/workers/project_service_worker.rb:8:in `perform' [...] ``` See merge request !767
To find the state of this project's repository at the time of any of these versions, check out the tags.
Loading