[
https://issues.apache.org/jira/browse/OPENMEETINGS-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13594945#comment-13594945
]
Guillaume Rembert edited comment on OPENMEETINGS-431 at 3/6/13 6:39 PM:
------------------------------------------------------------------------
>From what I see in the code, it is using the function "request.getScheme()" to
>construct the connection type that will inserted in the jnlp file.
Without fully understanding what it is doing here, I suspect that it is getting
the connection type from the openmeeting machine itself (which does not know
that there is a proxy in the middle).
The proxy is connected to the openmeeting machine through http on another port,
but the user is connected to the proxy through https, which relay the requests.
That's why my proposal was to use the client configuration file parameters with:
String protocol = request.getParameter("protocol");
if (protocol == null) {
throw new Exception("protocol is empty: " + protocol);
}
was (Author: guillaume.rembert):
From what I see in the code, it is using the function "request.getScheme()"
to construct the connection type that will inserted in the jnlp file.
Without fully understanding what it is doing here, I suspect that it is getting
the connection type from the openmeeting machine itself (which does not know
that there is a proxy in the middle).
That's why my proposal was to use the client configuration file parameters with:
String protocol = request.getParameter("protocol");
if (protocol == null) {
throw new Exception("protocol is empty: " + protocol);
}
> OpenMeetings behind a proxy doesn't work for screen sharing
> -----------------------------------------------------------
>
> Key: OPENMEETINGS-431
> URL: https://issues.apache.org/jira/browse/OPENMEETINGS-431
> Project: Openmeetings
> Issue Type: Bug
> Components: Screen-sharing
> Affects Versions: 2.1 Apache Release
> Environment: CentOS 6.3 + OpenMeetings Nightly Build
> Reporter: Guillaume Rembert
> Assignee: Maxim Solodovnik
> Priority: Minor
> Labels: apache, forward, front-end
> Fix For: 2.1 Apache Release
>
>
> First, thanks Maxim for your answer and sorry to re-open it, I used a newer
> version - 2.1.0.r1428678-04-01-2013 and still have some issues (not the
> latest, I just tried to upgrade, but it failed to start and I got many error
> messages), so maybe it is already fixed. Just to explain the configuration
> better:
> Public IPv4 Network - Forwarded Ports : 443/https to Machine 1 + 8088/rtmpT
> to Machine 2
> Machine 1 : Apache Server https over 443 / proxy to Machine 2 clear http
> Machine 2 : OpenMeetings Server - configuration: http over 5080 + rtmpT over
> 8088
> Everything works fine here except the part where you click on share screen,
> you download public_9.njlp and execute it in javaws.
> I get the following error:
> com.sun.deploy.net.FailedDownloadException: Unable to load resource:
> http://meeting.myorganisation.com:443/openmeetings/screensharing/red5.jar
> Which is normal as it try to get http on an https port. I tried to run it in
> my browser and get the confirmation:
> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> <html><head>
> <title>400 Bad Request</title>
> </head><body>
> <h1>Bad Request</h1>
> <p>Your browser sent a request that this server could not understand.<br />
> Reason: You're speaking plain HTTP to an SSL-enabled server port.<br />
> Instead use the HTTPS scheme to access this URL, please.<br />
> <blockquote>Hint: <a
> href="https://www.euryecetelecom.com/";><b>https://www.euryecetelecom.com/</b></a></blockquote></p>
> </body></html>
> Maybe I am not configuring it properly, but I think that it might be a tiny
> bug. For you to check, the related part of config.xml:
> <!--
> Port to use for the Server
> This port is used to connect to the http-servlet
> of the red5-servlet
> -->
> <red5httpport>443</red5httpport>
> <!--
> The protocol to use for the http connections
> for example upload/download of files
> -->
> <protocol>https</protocol>
> I'll put my hands in the code to try to solve this and help a bit, but in
> case you know where it is...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
