Bug 1071862

Summary: Generic HTTP upgrade generates 400 Bad Request response
Product: OpenShift Online Reporter: Jeff Mesnil <jmesnil>
Component: ContainersAssignee: Mrunal Patel <mpatel>
Status: CLOSED NOTABUG QA Contact: libra bugs <libra-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 2.xCC: bparees
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-03-04 23:46:10 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jeff Mesnil 2014-03-03 10:45:25 UTC
Description of problem:

WildFly 8 use a generic HTTP upgrade mechanism to upgrade from HTTP to native protocols (for JNDI, JMS, EJB, etc.).

When WildFly is hosted on OpenShift, the HTTP upgrade request fails with a "400 Bad request" response.
Is the HTTP upgrade mechanism limited to "Upgrade:websocket" in OpenShift or is there a way to upgrade to other protocols.

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


How reproducible:

Always

Steps to Reproduce:
1. Setup the WildFly 8 official cartridge and a sample example by following the instructions: https://github.com/wildfly/quickstart/blob/master/helloworld-jms/README.md
2. Run the Java client application

Actual results:
=> the HTTP Upgrade request fails.

Expected results:
=> the HTTP Upgrade request should work and the HTTP connection should be upgraded to a native connection (as it works when WildFly is used locally).

Additional info:

This can be easily (almost) reproduced usingby creating a WildFly 8 cartridge and using cURL:

# Upgrading to WebSocket (it works):

$ curl -v http://helloworldjms-jmesnil.rhcloud.com:8000 -H "Upgrade:websocket" -H "Connection:Upgrade" -H 'Sec-WebSocket-Key:tpVz/jJaED19ho4gWUrPtg==' -H 'Sec-WebSocket-Version:13'
* About to connect() to helloworldjms-jmesnil.rhcloud.com port 8000 (#0)
*   Trying 54.80.220.239...
* Connected to helloworldjms-jmesnil.rhcloud.com (54.80.220.239) port 8000 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.30.0
> Host: helloworldjms-jmesnil.rhcloud.com:8000
> Accept: */*
> Upgrade:websocket
> Connection:Upgrade
> Sec-WebSocket-Key:tpVz/jJaED19ho4gWUrPtg==
> Sec-WebSocket-Version:13
>
< HTTP/1.1 101 Switching Protocols
< Upgrade: websocket
< Connection: Upgrade
< Sec-WebSocket-Accept: 5X7WuRgzyVZPVnDuNgIva9LWj20=


# Upgrading to jboss-remoting protocol (it does not work):

$ curl -v http://helloworldjms-jmesnil.rhcloud.com:8000 -H "Upgrade:jboss-remoting" -H "Connection:Upgrade" -H 'Sec-JBossRemoting-Key:zOOUULuHXEwp265Nc+iimg=='
* About to connect() to helloworldjms-jmesnil.rhcloud.com port 8000 (#0)
*   Trying 54.80.220.239...
* Connected to helloworldjms-jmesnil.rhcloud.com (54.80.220.239) port 8000 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.30.0
> Host: helloworldjms-jmesnil.rhcloud.com:8000
> Accept: */*
> Upgrade:jboss-remoting
> Connection:Upgrade
> Sec-JBossRemoting-Key:zOOUULuHXEwp265Nc+iimg==
>
< HTTP/1.1 400 Bad Request
< Content-type: text/html
* no chunk, no close, no size. Assume close to signal end
<
* Closing connection 0

Comment 1 Ben Parees 2014-03-03 16:09:45 UTC
This works when using port-forwarding and making the connection directly to WF running in the gear, so the issue appears to be in the websocket proxy, not the WF cartridge.

Comment 2 Mrunal Patel 2014-03-04 20:55:16 UTC
The node web proxy was only designed to handle websocket upgrades. We will have to enhance it to handle other protocols.

Comment 3 Mrunal Patel 2014-03-04 23:46:10 UTC
I have added a card to track this request -
https://trello.com/c/swGjabeH/415-support-http-upgrade-to-protocols-besides-websocket