Bug 1025307 - HTTP GET request method to deployed Openshift application's URL with specified HTTP port 80 is redirected to weird HTTPS address.
Summary: HTTP GET request method to deployed Openshift application's URL with specifie...
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Containers
Version: 1.2.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: Brenton Leanhardt
QA Contact: libra bugs
URL:
Whiteboard:
Depends On: 1022956
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-31 12:57 UTC by Brenton Leanhardt
Modified: 2017-03-08 17:35 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 1022956
Environment:
Last Closed: 2014-02-04 14:37:06 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Brenton Leanhardt 2013-10-31 12:57:20 UTC
+++ This bug was initially created as a clone of Bug #1022956 +++

Description of problem:
HTTP GET request to deployed application on Openshift with specified HTTP port 80 (jbosseap cartridge) returns "302 Found" redirection to weird HTTPS address https://appname-namespace.rhcloud.com:80/app. Without specified port 80 Openshift behaves normally and returns "200 OK".

Version-Release number of selected component (if applicable):
Openshift online

How reproducible:
Always

Steps to Reproduce:
1.rhc app create testapp jbosseap --no-git
2.telnet testapp-namespace.rhcloud.com 80
>GET / HTTP/1.1
>Host: testapp-namespace.rhcloud.com:80

Actual results:
HTTP/1.1 302 Found
Date: Thu, 24 Oct 2013 10:43:28 GMT
Server: Apache/2.2.15 (Red Hat)
Location: https://testapp-wfkqa.rhcloud.com:80/app
Content-Length: 316
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="https://testapp-wfkqa.rhcloud.com:80/app">here</a>.</p>
<hr>
<address>Apache/2.2.15 (Red Hat) Server at testapp-wfkqa.rhcloud.com Port 80</address>
</body></html>


Expected results:
telnet testapp-namespace.rhcloud.com 80
>GET / HTTP/1.1
>Host: testapp-namespace.rhcloud.com

HTTP/1.1 200 OK
Date: Thu, 24 Oct 2013 10:45:37 GMT
Server: Apache-Coyote/1.1
Accept-Ranges: bytes
ETag: W/"6763-1382610862000"
Last-Modified: Thu, 24 Oct 2013 10:34:22 GMT
Content-Type: text/html
Content-Length: 6763
Vary: Accept-Encoding
.
.
.


Additional info:
Same behaviour with php, ruby and nodejs cartridges.

--- Additional comment from Emil Cervenan on 2013-10-24 08:47:25 EDT ---

This behaviour is not restricted to jbosseap cartridge only. See Additional info.

--- Additional comment from Rob Millner on 2013-10-24 14:25:02 EDT ---

Modified the regular expressions to strip port number off the host header when we construct an app name for matching.

https://github.com/openshift/origin-server/pull/3982

$ nc rmtest-rmillner0160.dev.rhcloud.com 80
GET / HTTP/1.1
Host: rmtest-rmillner0160.dev.rhcloud.com:80

HTTP/1.1 200 OK
Date: Thu, 24 Oct 2013 18:24:38 GMT
Server: Apache/2.2.15 (Red Hat)
Content-Length: 5235
Content-Type: text/html; charset=UTF-8
Vary: Accept-Encoding,User-Agent
ProxyTime: D=7782218

...

--- Additional comment from openshift-github-bot on 2013-10-24 21:36:49 EDT ---

Commit pushed to master at https://github.com/openshift/origin-server

https://github.com/openshift/origin-server/commit/a5930b7dd00f5bf3171ef8e4ef03f198b0401a1b
Bug 1022956 - Strip trailing port number off the host header.

--- Additional comment from Meng Bo on 2013-10-28 06:59:50 EDT ---

# curl -I http://php1-bmengdev.dev.rhcloud.com:80/
HTTP/1.1 200 OK
Date: Mon, 28 Oct 2013 10:50:57 GMT
Server: Apache/2.2.15 (Red Hat)
Content-Type: text/html; charset=UTF-8
Vary: Accept-Encoding,User-Agent
ProxyTime: D=2500


Checked on devenv_3953, the http request return correct code 200.

Move bug to verified.

Comment 1 Brenton Leanhardt 2013-10-31 12:59:08 UTC
Rob mentioned that this would apply cleanly to 1.2.

Comment 3 Brenton Leanhardt 2014-02-04 14:37:06 UTC
This is fixed in 2.0.  If a customer needs it for 1.2 we can consider backporting.


Note You need to log in before you can comment on or make changes to this bug.