Bug 1071862 - Generic HTTP upgrade generates 400 Bad Request response
Summary: Generic HTTP upgrade generates 400 Bad Request response
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: OpenShift Online
Classification: Red Hat
Component: Containers
Version: 2.x
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: Mrunal Patel
QA Contact: libra bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-03-03 10:45 UTC by Jeff Mesnil
Modified: 2015-05-14 23:35 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-03-04 23:46:10 UTC


Attachments (Terms of Use)

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


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