You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@openmeetings.apache.org by William Overstreet <wi...@gmail.com> on 2014/09/10 19:27:30 UTC

Problems using via IE

Trying to use openmeetings internally on our lan. I'm running into the
issue of only internet explorer is refusing work. all the other browsers
have no issues, reguardless of the OS. The login screen looks normal, post
login looks like http://i.imgur.com/nwhGX88.png , and if I try to join
straight to a meeting, all I get is that swirling icon in the middle of the
screen, the one before the loading bar appears.

The network is stuck behind a http proxy.

Re: Problems using via IE

Posted by Maxim Solodovnik <so...@gmail.com>.
Please reopen https://issues.apache.org/jira/browse/OPENMEETINGS-1087
In case still an issue

Build to test
https://builds.apache.org/view/M-R/view/OpenMeetings/job/Openmeetings%203.0.x/
build #65

Thanks for investigation

On 16 September 2014 22:28, Maxim Solodovnik <so...@gmail.com> wrote:

> I'll commit the changes into 3.0 and 3.1 branches and will start new
> SNAPSHOT build
> can you please check?
>
> On 16 September 2014 22:08, William Overstreet <
> william.ab.overstreet@gmail.com> wrote:
>
>> From all the help sites which have had to deal with this issue that I
>> have seen, it needs to be in place before everything else, including
>> javascript, right after the <html><head> tags on HTML. This all depends on
>> how IE behaves thou. I'm stuck with requiring compatibility view enabled
>> for all intranet sites because noone is going to update the older hardwired
>> for IE5.5 pages. I suggest you turn on that compatibilty view settings as
>> well while testing. If I knew how to handle tomcat's coyote better, I could
>> try setting configuration in coyote instead of using urlrewritefilter for
>> sending the x-ua-compability info in the response header.
>>
>>
>> On Tue, Sep 16, 2014 at 10:18 AM, Maxim Solodovnik <so...@gmail.com>
>> wrote:
>>
>>> so I should add
>>>
>>> <meta http-equiv="X-UA-Compatible" content="IE=Edge" />
>>>
>>> to all OM pages
>>> correct?
>>>
>>> On 16 September 2014 21:08, William Overstreet <
>>> william.ab.overstreet@gmail.com> wrote:
>>>
>>>> http://msdn.microsoft.com/en-us/library/ff955275%28v=vs.85%29.aspx
>>>>
>>>> On Mon, Sep 15, 2014 at 9:53 AM, William <
>>>> william.ab.overstreet@gmail.com> wrote:
>>>>
>>>>> You did supply the correct meta tags. The problem is that those tags
>>>>> have to be first, or ie will start processing with the older engine and
>>>>> ignore them. Throwing them in the http response header guarantees the page
>>>>> to be handled by the non-ie7 rendering engine. It is somewhere in the IE
>>>>> support spec that this is actually a proper way to do this. I'll have to
>>>>> dig up the document.
>>>>>
>>>>> On Sep 13, 2014, at 2:40, Maxim Solodovnik <so...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Maybe we can set some IE specific META? I can add it to the page if
>>>>> you can tell me with META should be added
>>>>>
>>>>> On 13 September 2014 01:39, William Overstreet <
>>>>> william.ab.overstreet@gmail.com> wrote:
>>>>>
>>>>>> Well, turns out that if compatibility view is enabled, and the first
>>>>>> thing through isn't the webs server telling the browser to use the latest
>>>>>> and greatest, the browser falls back to IE7 compatibility, which does not
>>>>>> work. I'm using urlrewritefilter-4.0.3.jar to make the internal tomcat web
>>>>>> server send the headers to force IE to use the latest.
>>>>>>
>>>>>> ${RED5_HOME}/webapps/openmeetings/WEB-INF/lib/urlrewritefilter-4.0.3.jar
>>>>>>
>>>>>> ${RED5_HOME}/webapps/openmeetings/WEB-INF/web.xml
>>>>>> ${RED5_HOME}/webapps/openmeetings/WEB-INF/urlrewrite.xml
>>>>>>
>>>>>> # diff web.xml web-old.xml
>>>>>> 37,48d36
>>>>>> <     <filter>
>>>>>> <         <filter-name>UrlRewriteFilter</filter-name>
>>>>>> <
>>>>>> <filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
>>>>>> <     </filter>
>>>>>> <
>>>>>> <     <filter-mapping>
>>>>>> <         <filter-name>UrlRewriteFilter</filter-name>
>>>>>> <         <url-pattern>/*</url-pattern>
>>>>>> <         <dispatcher>REQUEST</dispatcher>
>>>>>> <         <dispatcher>FORWARD</dispatcher>
>>>>>> <     </filter-mapping>
>>>>>> <
>>>>>>
>>>>>> # cat urlrewrite.xml
>>>>>> <?xml version="1.0" encoding="utf-8"?>
>>>>>> <!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 4.0//EN" "
>>>>>> http://www.tuckey.org/res/dtds/urlrewrite4.0.dtd">
>>>>>>
>>>>>> <urlrewrite>
>>>>>>
>>>>>>         <rule>
>>>>>>                 <condition
>>>>>> type="request-uri">^(/openmeetings/wicket.*)$</condition>
>>>>>>                 <condition name="user-agent">.*MSIE.*</condition>
>>>>>>                 <set type="response-header"
>>>>>> name="X-UA-Compatible">IE=Edge</set>
>>>>>>         </rule>
>>>>>>         <rule>
>>>>>>                 <condition
>>>>>> type="request-uri">^(/openmeetings/swf.*)$</condition>
>>>>>>                 <condition name="user-agent">.*MSIE.*</condition>
>>>>>>                 <set type="response-header"
>>>>>> name="X-UA-Compatible">IE=Edge</set>
>>>>>>         </rule>
>>>>>>         <rule>
>>>>>>                 <condition
>>>>>> type="request-uri">^(/openmeetings/)$</condition>
>>>>>>                 <condition name="user-agent">.*MSIE.*</condition>
>>>>>>                 <set type="response-header"
>>>>>> name="X-UA-Compatible">IE=Edge</set>
>>>>>>         </rule>
>>>>>>         <rule>
>>>>>>                 <condition
>>>>>> type="request-uri">^(/openmeetings/screen.upload.*)$</condition>
>>>>>>                 <condition name="user-agent">.*MSIE.*</condition>
>>>>>>                 <set type="response-header"
>>>>>> name="Cache-Control">max-age=5</set>
>>>>>>         </rule>
>>>>>> </urlrewrite>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Sep 11, 2014 at 11:17 AM, William Overstreet <
>>>>>> william.ab.overstreet@gmail.com> wrote:
>>>>>>
>>>>>>> Thanks for that, was getting nailed with the Compatibility view. For
>>>>>>> some reason corp says we need it turned on reasons. I guess I can edit the
>>>>>>> pages to present the correct html to force non-compatibility view.
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Sep 10, 2014 at 10:42 PM, Maxim Solodovnik <
>>>>>>> solomax666@gmail.com> wrote:
>>>>>>>
>>>>>>>> can you check IE without proxy?
>>>>>>>> can you check JS console in IE (F12 if I'm not mistaken)
>>>>>>>> It seems jquery and/or some CSS files were not loaded (maybe
>>>>>>>> because of proxy)
>>>>>>>>
>>>>>>>> On 11 September 2014 00:27, William Overstreet <
>>>>>>>> william.ab.overstreet@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Trying to use openmeetings internally on our lan. I'm running into
>>>>>>>>> the issue of only internet explorer is refusing work. all the other
>>>>>>>>> browsers have no issues, reguardless of the OS. The login screen looks
>>>>>>>>> normal, post login looks like http://i.imgur.com/nwhGX88.png ,
>>>>>>>>> and if I try to join straight to a meeting, all I get is that swirling icon
>>>>>>>>> in the middle of the screen, the one before the loading bar appears.
>>>>>>>>>
>>>>>>>>> The network is stuck behind a http proxy.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> WBR
>>>>>>>> Maxim aka solomax
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> WBR
>>>>> Maxim aka solomax
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> WBR
>>> Maxim aka solomax
>>>
>>
>>
>
>
> --
> WBR
> Maxim aka solomax
>



-- 
WBR
Maxim aka solomax

Re: Problems using via IE

Posted by Maxim Solodovnik <so...@gmail.com>.
I'll commit the changes into 3.0 and 3.1 branches and will start new
SNAPSHOT build
can you please check?

On 16 September 2014 22:08, William Overstreet <
william.ab.overstreet@gmail.com> wrote:

> From all the help sites which have had to deal with this issue that I have
> seen, it needs to be in place before everything else, including javascript,
> right after the <html><head> tags on HTML. This all depends on how IE
> behaves thou. I'm stuck with requiring compatibility view enabled for all
> intranet sites because noone is going to update the older hardwired for
> IE5.5 pages. I suggest you turn on that compatibilty view settings as well
> while testing. If I knew how to handle tomcat's coyote better, I could try
> setting configuration in coyote instead of using urlrewritefilter for
> sending the x-ua-compability info in the response header.
>
>
> On Tue, Sep 16, 2014 at 10:18 AM, Maxim Solodovnik <so...@gmail.com>
> wrote:
>
>> so I should add
>>
>> <meta http-equiv="X-UA-Compatible" content="IE=Edge" />
>>
>> to all OM pages
>> correct?
>>
>> On 16 September 2014 21:08, William Overstreet <
>> william.ab.overstreet@gmail.com> wrote:
>>
>>> http://msdn.microsoft.com/en-us/library/ff955275%28v=vs.85%29.aspx
>>>
>>> On Mon, Sep 15, 2014 at 9:53 AM, William <
>>> william.ab.overstreet@gmail.com> wrote:
>>>
>>>> You did supply the correct meta tags. The problem is that those tags
>>>> have to be first, or ie will start processing with the older engine and
>>>> ignore them. Throwing them in the http response header guarantees the page
>>>> to be handled by the non-ie7 rendering engine. It is somewhere in the IE
>>>> support spec that this is actually a proper way to do this. I'll have to
>>>> dig up the document.
>>>>
>>>> On Sep 13, 2014, at 2:40, Maxim Solodovnik <so...@gmail.com>
>>>> wrote:
>>>>
>>>> Maybe we can set some IE specific META? I can add it to the page if you
>>>> can tell me with META should be added
>>>>
>>>> On 13 September 2014 01:39, William Overstreet <
>>>> william.ab.overstreet@gmail.com> wrote:
>>>>
>>>>> Well, turns out that if compatibility view is enabled, and the first
>>>>> thing through isn't the webs server telling the browser to use the latest
>>>>> and greatest, the browser falls back to IE7 compatibility, which does not
>>>>> work. I'm using urlrewritefilter-4.0.3.jar to make the internal tomcat web
>>>>> server send the headers to force IE to use the latest.
>>>>>
>>>>> ${RED5_HOME}/webapps/openmeetings/WEB-INF/lib/urlrewritefilter-4.0.3.jar
>>>>>
>>>>> ${RED5_HOME}/webapps/openmeetings/WEB-INF/web.xml
>>>>> ${RED5_HOME}/webapps/openmeetings/WEB-INF/urlrewrite.xml
>>>>>
>>>>> # diff web.xml web-old.xml
>>>>> 37,48d36
>>>>> <     <filter>
>>>>> <         <filter-name>UrlRewriteFilter</filter-name>
>>>>> <
>>>>> <filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
>>>>> <     </filter>
>>>>> <
>>>>> <     <filter-mapping>
>>>>> <         <filter-name>UrlRewriteFilter</filter-name>
>>>>> <         <url-pattern>/*</url-pattern>
>>>>> <         <dispatcher>REQUEST</dispatcher>
>>>>> <         <dispatcher>FORWARD</dispatcher>
>>>>> <     </filter-mapping>
>>>>> <
>>>>>
>>>>> # cat urlrewrite.xml
>>>>> <?xml version="1.0" encoding="utf-8"?>
>>>>> <!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 4.0//EN" "
>>>>> http://www.tuckey.org/res/dtds/urlrewrite4.0.dtd">
>>>>>
>>>>> <urlrewrite>
>>>>>
>>>>>         <rule>
>>>>>                 <condition
>>>>> type="request-uri">^(/openmeetings/wicket.*)$</condition>
>>>>>                 <condition name="user-agent">.*MSIE.*</condition>
>>>>>                 <set type="response-header"
>>>>> name="X-UA-Compatible">IE=Edge</set>
>>>>>         </rule>
>>>>>         <rule>
>>>>>                 <condition
>>>>> type="request-uri">^(/openmeetings/swf.*)$</condition>
>>>>>                 <condition name="user-agent">.*MSIE.*</condition>
>>>>>                 <set type="response-header"
>>>>> name="X-UA-Compatible">IE=Edge</set>
>>>>>         </rule>
>>>>>         <rule>
>>>>>                 <condition
>>>>> type="request-uri">^(/openmeetings/)$</condition>
>>>>>                 <condition name="user-agent">.*MSIE.*</condition>
>>>>>                 <set type="response-header"
>>>>> name="X-UA-Compatible">IE=Edge</set>
>>>>>         </rule>
>>>>>         <rule>
>>>>>                 <condition
>>>>> type="request-uri">^(/openmeetings/screen.upload.*)$</condition>
>>>>>                 <condition name="user-agent">.*MSIE.*</condition>
>>>>>                 <set type="response-header"
>>>>> name="Cache-Control">max-age=5</set>
>>>>>         </rule>
>>>>> </urlrewrite>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Sep 11, 2014 at 11:17 AM, William Overstreet <
>>>>> william.ab.overstreet@gmail.com> wrote:
>>>>>
>>>>>> Thanks for that, was getting nailed with the Compatibility view. For
>>>>>> some reason corp says we need it turned on reasons. I guess I can edit the
>>>>>> pages to present the correct html to force non-compatibility view.
>>>>>>
>>>>>>
>>>>>> On Wed, Sep 10, 2014 at 10:42 PM, Maxim Solodovnik <
>>>>>> solomax666@gmail.com> wrote:
>>>>>>
>>>>>>> can you check IE without proxy?
>>>>>>> can you check JS console in IE (F12 if I'm not mistaken)
>>>>>>> It seems jquery and/or some CSS files were not loaded (maybe because
>>>>>>> of proxy)
>>>>>>>
>>>>>>> On 11 September 2014 00:27, William Overstreet <
>>>>>>> william.ab.overstreet@gmail.com> wrote:
>>>>>>>
>>>>>>>> Trying to use openmeetings internally on our lan. I'm running into
>>>>>>>> the issue of only internet explorer is refusing work. all the other
>>>>>>>> browsers have no issues, reguardless of the OS. The login screen looks
>>>>>>>> normal, post login looks like http://i.imgur.com/nwhGX88.png , and
>>>>>>>> if I try to join straight to a meeting, all I get is that swirling icon in
>>>>>>>> the middle of the screen, the one before the loading bar appears.
>>>>>>>>
>>>>>>>> The network is stuck behind a http proxy.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> WBR
>>>>>>> Maxim aka solomax
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> WBR
>>>> Maxim aka solomax
>>>>
>>>>
>>>
>>
>>
>> --
>> WBR
>> Maxim aka solomax
>>
>
>


-- 
WBR
Maxim aka solomax

Re: Problems using via IE

Posted by William Overstreet <wi...@gmail.com>.
>From all the help sites which have had to deal with this issue that I have
seen, it needs to be in place before everything else, including javascript,
right after the <html><head> tags on HTML. This all depends on how IE
behaves thou. I'm stuck with requiring compatibility view enabled for all
intranet sites because noone is going to update the older hardwired for
IE5.5 pages. I suggest you turn on that compatibilty view settings as well
while testing. If I knew how to handle tomcat's coyote better, I could try
setting configuration in coyote instead of using urlrewritefilter for
sending the x-ua-compability info in the response header.


On Tue, Sep 16, 2014 at 10:18 AM, Maxim Solodovnik <so...@gmail.com>
wrote:

> so I should add
>
> <meta http-equiv="X-UA-Compatible" content="IE=Edge" />
>
> to all OM pages
> correct?
>
> On 16 September 2014 21:08, William Overstreet <
> william.ab.overstreet@gmail.com> wrote:
>
>> http://msdn.microsoft.com/en-us/library/ff955275%28v=vs.85%29.aspx
>>
>> On Mon, Sep 15, 2014 at 9:53 AM, William <william.ab.overstreet@gmail.com
>> > wrote:
>>
>>> You did supply the correct meta tags. The problem is that those tags
>>> have to be first, or ie will start processing with the older engine and
>>> ignore them. Throwing them in the http response header guarantees the page
>>> to be handled by the non-ie7 rendering engine. It is somewhere in the IE
>>> support spec that this is actually a proper way to do this. I'll have to
>>> dig up the document.
>>>
>>> On Sep 13, 2014, at 2:40, Maxim Solodovnik <so...@gmail.com> wrote:
>>>
>>> Maybe we can set some IE specific META? I can add it to the page if you
>>> can tell me with META should be added
>>>
>>> On 13 September 2014 01:39, William Overstreet <
>>> william.ab.overstreet@gmail.com> wrote:
>>>
>>>> Well, turns out that if compatibility view is enabled, and the first
>>>> thing through isn't the webs server telling the browser to use the latest
>>>> and greatest, the browser falls back to IE7 compatibility, which does not
>>>> work. I'm using urlrewritefilter-4.0.3.jar to make the internal tomcat web
>>>> server send the headers to force IE to use the latest.
>>>>
>>>> ${RED5_HOME}/webapps/openmeetings/WEB-INF/lib/urlrewritefilter-4.0.3.jar
>>>>
>>>> ${RED5_HOME}/webapps/openmeetings/WEB-INF/web.xml
>>>> ${RED5_HOME}/webapps/openmeetings/WEB-INF/urlrewrite.xml
>>>>
>>>> # diff web.xml web-old.xml
>>>> 37,48d36
>>>> <     <filter>
>>>> <         <filter-name>UrlRewriteFilter</filter-name>
>>>> <
>>>> <filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
>>>> <     </filter>
>>>> <
>>>> <     <filter-mapping>
>>>> <         <filter-name>UrlRewriteFilter</filter-name>
>>>> <         <url-pattern>/*</url-pattern>
>>>> <         <dispatcher>REQUEST</dispatcher>
>>>> <         <dispatcher>FORWARD</dispatcher>
>>>> <     </filter-mapping>
>>>> <
>>>>
>>>> # cat urlrewrite.xml
>>>> <?xml version="1.0" encoding="utf-8"?>
>>>> <!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 4.0//EN" "
>>>> http://www.tuckey.org/res/dtds/urlrewrite4.0.dtd">
>>>>
>>>> <urlrewrite>
>>>>
>>>>         <rule>
>>>>                 <condition
>>>> type="request-uri">^(/openmeetings/wicket.*)$</condition>
>>>>                 <condition name="user-agent">.*MSIE.*</condition>
>>>>                 <set type="response-header"
>>>> name="X-UA-Compatible">IE=Edge</set>
>>>>         </rule>
>>>>         <rule>
>>>>                 <condition
>>>> type="request-uri">^(/openmeetings/swf.*)$</condition>
>>>>                 <condition name="user-agent">.*MSIE.*</condition>
>>>>                 <set type="response-header"
>>>> name="X-UA-Compatible">IE=Edge</set>
>>>>         </rule>
>>>>         <rule>
>>>>                 <condition
>>>> type="request-uri">^(/openmeetings/)$</condition>
>>>>                 <condition name="user-agent">.*MSIE.*</condition>
>>>>                 <set type="response-header"
>>>> name="X-UA-Compatible">IE=Edge</set>
>>>>         </rule>
>>>>         <rule>
>>>>                 <condition
>>>> type="request-uri">^(/openmeetings/screen.upload.*)$</condition>
>>>>                 <condition name="user-agent">.*MSIE.*</condition>
>>>>                 <set type="response-header"
>>>> name="Cache-Control">max-age=5</set>
>>>>         </rule>
>>>> </urlrewrite>
>>>>
>>>>
>>>>
>>>> On Thu, Sep 11, 2014 at 11:17 AM, William Overstreet <
>>>> william.ab.overstreet@gmail.com> wrote:
>>>>
>>>>> Thanks for that, was getting nailed with the Compatibility view. For
>>>>> some reason corp says we need it turned on reasons. I guess I can edit the
>>>>> pages to present the correct html to force non-compatibility view.
>>>>>
>>>>>
>>>>> On Wed, Sep 10, 2014 at 10:42 PM, Maxim Solodovnik <
>>>>> solomax666@gmail.com> wrote:
>>>>>
>>>>>> can you check IE without proxy?
>>>>>> can you check JS console in IE (F12 if I'm not mistaken)
>>>>>> It seems jquery and/or some CSS files were not loaded (maybe because
>>>>>> of proxy)
>>>>>>
>>>>>> On 11 September 2014 00:27, William Overstreet <
>>>>>> william.ab.overstreet@gmail.com> wrote:
>>>>>>
>>>>>>> Trying to use openmeetings internally on our lan. I'm running into
>>>>>>> the issue of only internet explorer is refusing work. all the other
>>>>>>> browsers have no issues, reguardless of the OS. The login screen looks
>>>>>>> normal, post login looks like http://i.imgur.com/nwhGX88.png , and
>>>>>>> if I try to join straight to a meeting, all I get is that swirling icon in
>>>>>>> the middle of the screen, the one before the loading bar appears.
>>>>>>>
>>>>>>> The network is stuck behind a http proxy.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> WBR
>>>>>> Maxim aka solomax
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> WBR
>>> Maxim aka solomax
>>>
>>>
>>
>
>
> --
> WBR
> Maxim aka solomax
>

Re: Problems using via IE

Posted by Maxim Solodovnik <so...@gmail.com>.
so I should add

<meta http-equiv="X-UA-Compatible" content="IE=Edge" />

to all OM pages
correct?

On 16 September 2014 21:08, William Overstreet <
william.ab.overstreet@gmail.com> wrote:

> http://msdn.microsoft.com/en-us/library/ff955275%28v=vs.85%29.aspx
>
> On Mon, Sep 15, 2014 at 9:53 AM, William <wi...@gmail.com>
> wrote:
>
>> You did supply the correct meta tags. The problem is that those tags have
>> to be first, or ie will start processing with the older engine and ignore
>> them. Throwing them in the http response header guarantees the page to be
>> handled by the non-ie7 rendering engine. It is somewhere in the IE support
>> spec that this is actually a proper way to do this. I'll have to dig up the
>> document.
>>
>> On Sep 13, 2014, at 2:40, Maxim Solodovnik <so...@gmail.com> wrote:
>>
>> Maybe we can set some IE specific META? I can add it to the page if you
>> can tell me with META should be added
>>
>> On 13 September 2014 01:39, William Overstreet <
>> william.ab.overstreet@gmail.com> wrote:
>>
>>> Well, turns out that if compatibility view is enabled, and the first
>>> thing through isn't the webs server telling the browser to use the latest
>>> and greatest, the browser falls back to IE7 compatibility, which does not
>>> work. I'm using urlrewritefilter-4.0.3.jar to make the internal tomcat web
>>> server send the headers to force IE to use the latest.
>>>
>>> ${RED5_HOME}/webapps/openmeetings/WEB-INF/lib/urlrewritefilter-4.0.3.jar
>>> ${RED5_HOME}/webapps/openmeetings/WEB-INF/web.xml
>>> ${RED5_HOME}/webapps/openmeetings/WEB-INF/urlrewrite.xml
>>>
>>> # diff web.xml web-old.xml
>>> 37,48d36
>>> <     <filter>
>>> <         <filter-name>UrlRewriteFilter</filter-name>
>>> <
>>> <filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
>>> <     </filter>
>>> <
>>> <     <filter-mapping>
>>> <         <filter-name>UrlRewriteFilter</filter-name>
>>> <         <url-pattern>/*</url-pattern>
>>> <         <dispatcher>REQUEST</dispatcher>
>>> <         <dispatcher>FORWARD</dispatcher>
>>> <     </filter-mapping>
>>> <
>>>
>>> # cat urlrewrite.xml
>>> <?xml version="1.0" encoding="utf-8"?>
>>> <!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 4.0//EN" "
>>> http://www.tuckey.org/res/dtds/urlrewrite4.0.dtd">
>>>
>>> <urlrewrite>
>>>
>>>         <rule>
>>>                 <condition
>>> type="request-uri">^(/openmeetings/wicket.*)$</condition>
>>>                 <condition name="user-agent">.*MSIE.*</condition>
>>>                 <set type="response-header"
>>> name="X-UA-Compatible">IE=Edge</set>
>>>         </rule>
>>>         <rule>
>>>                 <condition
>>> type="request-uri">^(/openmeetings/swf.*)$</condition>
>>>                 <condition name="user-agent">.*MSIE.*</condition>
>>>                 <set type="response-header"
>>> name="X-UA-Compatible">IE=Edge</set>
>>>         </rule>
>>>         <rule>
>>>                 <condition
>>> type="request-uri">^(/openmeetings/)$</condition>
>>>                 <condition name="user-agent">.*MSIE.*</condition>
>>>                 <set type="response-header"
>>> name="X-UA-Compatible">IE=Edge</set>
>>>         </rule>
>>>         <rule>
>>>                 <condition
>>> type="request-uri">^(/openmeetings/screen.upload.*)$</condition>
>>>                 <condition name="user-agent">.*MSIE.*</condition>
>>>                 <set type="response-header"
>>> name="Cache-Control">max-age=5</set>
>>>         </rule>
>>> </urlrewrite>
>>>
>>>
>>>
>>> On Thu, Sep 11, 2014 at 11:17 AM, William Overstreet <
>>> william.ab.overstreet@gmail.com> wrote:
>>>
>>>> Thanks for that, was getting nailed with the Compatibility view. For
>>>> some reason corp says we need it turned on reasons. I guess I can edit the
>>>> pages to present the correct html to force non-compatibility view.
>>>>
>>>>
>>>> On Wed, Sep 10, 2014 at 10:42 PM, Maxim Solodovnik <
>>>> solomax666@gmail.com> wrote:
>>>>
>>>>> can you check IE without proxy?
>>>>> can you check JS console in IE (F12 if I'm not mistaken)
>>>>> It seems jquery and/or some CSS files were not loaded (maybe because
>>>>> of proxy)
>>>>>
>>>>> On 11 September 2014 00:27, William Overstreet <
>>>>> william.ab.overstreet@gmail.com> wrote:
>>>>>
>>>>>> Trying to use openmeetings internally on our lan. I'm running into
>>>>>> the issue of only internet explorer is refusing work. all the other
>>>>>> browsers have no issues, reguardless of the OS. The login screen looks
>>>>>> normal, post login looks like http://i.imgur.com/nwhGX88.png , and
>>>>>> if I try to join straight to a meeting, all I get is that swirling icon in
>>>>>> the middle of the screen, the one before the loading bar appears.
>>>>>>
>>>>>> The network is stuck behind a http proxy.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> WBR
>>>>> Maxim aka solomax
>>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> WBR
>> Maxim aka solomax
>>
>>
>


-- 
WBR
Maxim aka solomax

Re: Problems using via IE

Posted by William Overstreet <wi...@gmail.com>.
http://msdn.microsoft.com/en-us/library/ff955275%28v=vs.85%29.aspx

On Mon, Sep 15, 2014 at 9:53 AM, William <wi...@gmail.com>
wrote:

> You did supply the correct meta tags. The problem is that those tags have
> to be first, or ie will start processing with the older engine and ignore
> them. Throwing them in the http response header guarantees the page to be
> handled by the non-ie7 rendering engine. It is somewhere in the IE support
> spec that this is actually a proper way to do this. I'll have to dig up the
> document.
>
> On Sep 13, 2014, at 2:40, Maxim Solodovnik <so...@gmail.com> wrote:
>
> Maybe we can set some IE specific META? I can add it to the page if you
> can tell me with META should be added
>
> On 13 September 2014 01:39, William Overstreet <
> william.ab.overstreet@gmail.com> wrote:
>
>> Well, turns out that if compatibility view is enabled, and the first
>> thing through isn't the webs server telling the browser to use the latest
>> and greatest, the browser falls back to IE7 compatibility, which does not
>> work. I'm using urlrewritefilter-4.0.3.jar to make the internal tomcat web
>> server send the headers to force IE to use the latest.
>>
>> ${RED5_HOME}/webapps/openmeetings/WEB-INF/lib/urlrewritefilter-4.0.3.jar
>> ${RED5_HOME}/webapps/openmeetings/WEB-INF/web.xml
>> ${RED5_HOME}/webapps/openmeetings/WEB-INF/urlrewrite.xml
>>
>> # diff web.xml web-old.xml
>> 37,48d36
>> <     <filter>
>> <         <filter-name>UrlRewriteFilter</filter-name>
>> <
>> <filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
>> <     </filter>
>> <
>> <     <filter-mapping>
>> <         <filter-name>UrlRewriteFilter</filter-name>
>> <         <url-pattern>/*</url-pattern>
>> <         <dispatcher>REQUEST</dispatcher>
>> <         <dispatcher>FORWARD</dispatcher>
>> <     </filter-mapping>
>> <
>>
>> # cat urlrewrite.xml
>> <?xml version="1.0" encoding="utf-8"?>
>> <!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 4.0//EN" "
>> http://www.tuckey.org/res/dtds/urlrewrite4.0.dtd">
>>
>> <urlrewrite>
>>
>>         <rule>
>>                 <condition
>> type="request-uri">^(/openmeetings/wicket.*)$</condition>
>>                 <condition name="user-agent">.*MSIE.*</condition>
>>                 <set type="response-header"
>> name="X-UA-Compatible">IE=Edge</set>
>>         </rule>
>>         <rule>
>>                 <condition
>> type="request-uri">^(/openmeetings/swf.*)$</condition>
>>                 <condition name="user-agent">.*MSIE.*</condition>
>>                 <set type="response-header"
>> name="X-UA-Compatible">IE=Edge</set>
>>         </rule>
>>         <rule>
>>                 <condition
>> type="request-uri">^(/openmeetings/)$</condition>
>>                 <condition name="user-agent">.*MSIE.*</condition>
>>                 <set type="response-header"
>> name="X-UA-Compatible">IE=Edge</set>
>>         </rule>
>>         <rule>
>>                 <condition
>> type="request-uri">^(/openmeetings/screen.upload.*)$</condition>
>>                 <condition name="user-agent">.*MSIE.*</condition>
>>                 <set type="response-header"
>> name="Cache-Control">max-age=5</set>
>>         </rule>
>> </urlrewrite>
>>
>>
>>
>> On Thu, Sep 11, 2014 at 11:17 AM, William Overstreet <
>> william.ab.overstreet@gmail.com> wrote:
>>
>>> Thanks for that, was getting nailed with the Compatibility view. For
>>> some reason corp says we need it turned on reasons. I guess I can edit the
>>> pages to present the correct html to force non-compatibility view.
>>>
>>>
>>> On Wed, Sep 10, 2014 at 10:42 PM, Maxim Solodovnik <solomax666@gmail.com
>>> > wrote:
>>>
>>>> can you check IE without proxy?
>>>> can you check JS console in IE (F12 if I'm not mistaken)
>>>> It seems jquery and/or some CSS files were not loaded (maybe because of
>>>> proxy)
>>>>
>>>> On 11 September 2014 00:27, William Overstreet <
>>>> william.ab.overstreet@gmail.com> wrote:
>>>>
>>>>> Trying to use openmeetings internally on our lan. I'm running into the
>>>>> issue of only internet explorer is refusing work. all the other browsers
>>>>> have no issues, reguardless of the OS. The login screen looks normal, post
>>>>> login looks like http://i.imgur.com/nwhGX88.png , and if I try to
>>>>> join straight to a meeting, all I get is that swirling icon in the middle
>>>>> of the screen, the one before the loading bar appears.
>>>>>
>>>>> The network is stuck behind a http proxy.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> WBR
>>>> Maxim aka solomax
>>>>
>>>
>>>
>>
>
>
> --
> WBR
> Maxim aka solomax
>
>

Re: Problems using via IE

Posted by William <wi...@gmail.com>.
You did supply the correct meta tags. The problem is that those tags have to be first, or ie will start processing with the older engine and ignore them. Throwing them in the http response header guarantees the page to be handled by the non-ie7 rendering engine. It is somewhere in the IE support spec that this is actually a proper way to do this. I'll have to dig up the document. 

> On Sep 13, 2014, at 2:40, Maxim Solodovnik <so...@gmail.com> wrote:
> 
> Maybe we can set some IE specific META? I can add it to the page if you can tell me with META should be added
> 
>> On 13 September 2014 01:39, William Overstreet <wi...@gmail.com> wrote:
>> Well, turns out that if compatibility view is enabled, and the first thing through isn't the webs server telling the browser to use the latest and greatest, the browser falls back to IE7 compatibility, which does not work. I'm using urlrewritefilter-4.0.3.jar to make the internal tomcat web server send the headers to force IE to use the latest.
>> 
>> ${RED5_HOME}/webapps/openmeetings/WEB-INF/lib/urlrewritefilter-4.0.3.jar 
>> ${RED5_HOME}/webapps/openmeetings/WEB-INF/web.xml
>> ${RED5_HOME}/webapps/openmeetings/WEB-INF/urlrewrite.xml
>> 
>> # diff web.xml web-old.xml 
>> 37,48d36
>> <     <filter>
>> <         <filter-name>UrlRewriteFilter</filter-name>
>> <         <filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
>> <     </filter>
>> < 
>> <     <filter-mapping>
>> <         <filter-name>UrlRewriteFilter</filter-name>
>> <         <url-pattern>/*</url-pattern>
>> <         <dispatcher>REQUEST</dispatcher>
>> <         <dispatcher>FORWARD</dispatcher>
>> <     </filter-mapping>
>> < 
>> 
>> # cat urlrewrite.xml
>> <?xml version="1.0" encoding="utf-8"?>
>> <!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 4.0//EN" "http://www.tuckey.org/res/dtds/urlrewrite4.0.dtd">
>> 
>> <urlrewrite>
>> 
>>         <rule>
>>                 <condition type="request-uri">^(/openmeetings/wicket.*)$</condition>
>>                 <condition name="user-agent">.*MSIE.*</condition>
>>                 <set type="response-header" name="X-UA-Compatible">IE=Edge</set>
>>         </rule>
>>         <rule>
>>                 <condition type="request-uri">^(/openmeetings/swf.*)$</condition>
>>                 <condition name="user-agent">.*MSIE.*</condition>
>>                 <set type="response-header" name="X-UA-Compatible">IE=Edge</set>
>>         </rule>
>>         <rule>
>>                 <condition type="request-uri">^(/openmeetings/)$</condition>
>>                 <condition name="user-agent">.*MSIE.*</condition>
>>                 <set type="response-header" name="X-UA-Compatible">IE=Edge</set>
>>         </rule>
>>         <rule>
>>                 <condition type="request-uri">^(/openmeetings/screen.upload.*)$</condition>
>>                 <condition name="user-agent">.*MSIE.*</condition>
>>                 <set type="response-header" name="Cache-Control">max-age=5</set>
>>         </rule>
>> </urlrewrite>
>> 
>> 
>> 
>>> On Thu, Sep 11, 2014 at 11:17 AM, William Overstreet <wi...@gmail.com> wrote:
>>> Thanks for that, was getting nailed with the Compatibility view. For some reason corp says we need it turned on reasons. I guess I can edit the pages to present the correct html to force non-compatibility view.
>>> 
>>> 
>>>> On Wed, Sep 10, 2014 at 10:42 PM, Maxim Solodovnik <so...@gmail.com> wrote:
>>>> can you check IE without proxy?
>>>> can you check JS console in IE (F12 if I'm not mistaken)
>>>> It seems jquery and/or some CSS files were not loaded (maybe because of proxy)
>>>> 
>>>>> On 11 September 2014 00:27, William Overstreet <wi...@gmail.com> wrote:
>>>>> Trying to use openmeetings internally on our lan. I'm running into the issue of only internet explorer is refusing work. all the other browsers have no issues, reguardless of the OS. The login screen looks normal, post login looks like http://i.imgur.com/nwhGX88.png , and if I try to join straight to a meeting, all I get is that swirling icon in the middle of the screen, the one before the loading bar appears.
>>>>> 
>>>>> The network is stuck behind a http proxy.
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> WBR
>>>> Maxim aka solomax
> 
> 
> 
> -- 
> WBR
> Maxim aka solomax

Re: Problems using via IE

Posted by Maxim Solodovnik <so...@gmail.com>.
Maybe we can set some IE specific META? I can add it to the page if you can
tell me with META should be added

On 13 September 2014 01:39, William Overstreet <
william.ab.overstreet@gmail.com> wrote:

> Well, turns out that if compatibility view is enabled, and the first thing
> through isn't the webs server telling the browser to use the latest and
> greatest, the browser falls back to IE7 compatibility, which does not work.
> I'm using urlrewritefilter-4.0.3.jar to make the internal tomcat web server
> send the headers to force IE to use the latest.
>
> ${RED5_HOME}/webapps/openmeetings/WEB-INF/lib/urlrewritefilter-4.0.3.jar
> ${RED5_HOME}/webapps/openmeetings/WEB-INF/web.xml
> ${RED5_HOME}/webapps/openmeetings/WEB-INF/urlrewrite.xml
>
> # diff web.xml web-old.xml
> 37,48d36
> <     <filter>
> <         <filter-name>UrlRewriteFilter</filter-name>
> <
> <filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
> <     </filter>
> <
> <     <filter-mapping>
> <         <filter-name>UrlRewriteFilter</filter-name>
> <         <url-pattern>/*</url-pattern>
> <         <dispatcher>REQUEST</dispatcher>
> <         <dispatcher>FORWARD</dispatcher>
> <     </filter-mapping>
> <
>
> # cat urlrewrite.xml
> <?xml version="1.0" encoding="utf-8"?>
> <!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 4.0//EN" "
> http://www.tuckey.org/res/dtds/urlrewrite4.0.dtd">
>
> <urlrewrite>
>
>         <rule>
>                 <condition
> type="request-uri">^(/openmeetings/wicket.*)$</condition>
>                 <condition name="user-agent">.*MSIE.*</condition>
>                 <set type="response-header"
> name="X-UA-Compatible">IE=Edge</set>
>         </rule>
>         <rule>
>                 <condition
> type="request-uri">^(/openmeetings/swf.*)$</condition>
>                 <condition name="user-agent">.*MSIE.*</condition>
>                 <set type="response-header"
> name="X-UA-Compatible">IE=Edge</set>
>         </rule>
>         <rule>
>                 <condition
> type="request-uri">^(/openmeetings/)$</condition>
>                 <condition name="user-agent">.*MSIE.*</condition>
>                 <set type="response-header"
> name="X-UA-Compatible">IE=Edge</set>
>         </rule>
>         <rule>
>                 <condition
> type="request-uri">^(/openmeetings/screen.upload.*)$</condition>
>                 <condition name="user-agent">.*MSIE.*</condition>
>                 <set type="response-header"
> name="Cache-Control">max-age=5</set>
>         </rule>
> </urlrewrite>
>
>
>
> On Thu, Sep 11, 2014 at 11:17 AM, William Overstreet <
> william.ab.overstreet@gmail.com> wrote:
>
>> Thanks for that, was getting nailed with the Compatibility view. For some
>> reason corp says we need it turned on reasons. I guess I can edit the pages
>> to present the correct html to force non-compatibility view.
>>
>>
>> On Wed, Sep 10, 2014 at 10:42 PM, Maxim Solodovnik <so...@gmail.com>
>> wrote:
>>
>>> can you check IE without proxy?
>>> can you check JS console in IE (F12 if I'm not mistaken)
>>> It seems jquery and/or some CSS files were not loaded (maybe because of
>>> proxy)
>>>
>>> On 11 September 2014 00:27, William Overstreet <
>>> william.ab.overstreet@gmail.com> wrote:
>>>
>>>> Trying to use openmeetings internally on our lan. I'm running into the
>>>> issue of only internet explorer is refusing work. all the other browsers
>>>> have no issues, reguardless of the OS. The login screen looks normal, post
>>>> login looks like http://i.imgur.com/nwhGX88.png , and if I try to join
>>>> straight to a meeting, all I get is that swirling icon in the middle of the
>>>> screen, the one before the loading bar appears.
>>>>
>>>> The network is stuck behind a http proxy.
>>>>
>>>
>>>
>>>
>>> --
>>> WBR
>>> Maxim aka solomax
>>>
>>
>>
>


-- 
WBR
Maxim aka solomax

Re: Problems using via IE

Posted by William Overstreet <wi...@gmail.com>.
Well, turns out that if compatibility view is enabled, and the first thing
through isn't the webs server telling the browser to use the latest and
greatest, the browser falls back to IE7 compatibility, which does not work.
I'm using urlrewritefilter-4.0.3.jar to make the internal tomcat web server
send the headers to force IE to use the latest.

${RED5_HOME}/webapps/openmeetings/WEB-INF/lib/urlrewritefilter-4.0.3.jar
${RED5_HOME}/webapps/openmeetings/WEB-INF/web.xml
${RED5_HOME}/webapps/openmeetings/WEB-INF/urlrewrite.xml

# diff web.xml web-old.xml
37,48d36
<     <filter>
<         <filter-name>UrlRewriteFilter</filter-name>
<
<filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
<     </filter>
<
<     <filter-mapping>
<         <filter-name>UrlRewriteFilter</filter-name>
<         <url-pattern>/*</url-pattern>
<         <dispatcher>REQUEST</dispatcher>
<         <dispatcher>FORWARD</dispatcher>
<     </filter-mapping>
<

# cat urlrewrite.xml
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 4.0//EN" "
http://www.tuckey.org/res/dtds/urlrewrite4.0.dtd">

<urlrewrite>

        <rule>
                <condition
type="request-uri">^(/openmeetings/wicket.*)$</condition>
                <condition name="user-agent">.*MSIE.*</condition>
                <set type="response-header"
name="X-UA-Compatible">IE=Edge</set>
        </rule>
        <rule>
                <condition
type="request-uri">^(/openmeetings/swf.*)$</condition>
                <condition name="user-agent">.*MSIE.*</condition>
                <set type="response-header"
name="X-UA-Compatible">IE=Edge</set>
        </rule>
        <rule>
                <condition type="request-uri">^(/openmeetings/)$</condition>
                <condition name="user-agent">.*MSIE.*</condition>
                <set type="response-header"
name="X-UA-Compatible">IE=Edge</set>
        </rule>
        <rule>
                <condition
type="request-uri">^(/openmeetings/screen.upload.*)$</condition>
                <condition name="user-agent">.*MSIE.*</condition>
                <set type="response-header"
name="Cache-Control">max-age=5</set>
        </rule>
</urlrewrite>



On Thu, Sep 11, 2014 at 11:17 AM, William Overstreet <
william.ab.overstreet@gmail.com> wrote:

> Thanks for that, was getting nailed with the Compatibility view. For some
> reason corp says we need it turned on reasons. I guess I can edit the pages
> to present the correct html to force non-compatibility view.
>
>
> On Wed, Sep 10, 2014 at 10:42 PM, Maxim Solodovnik <so...@gmail.com>
> wrote:
>
>> can you check IE without proxy?
>> can you check JS console in IE (F12 if I'm not mistaken)
>> It seems jquery and/or some CSS files were not loaded (maybe because of
>> proxy)
>>
>> On 11 September 2014 00:27, William Overstreet <
>> william.ab.overstreet@gmail.com> wrote:
>>
>>> Trying to use openmeetings internally on our lan. I'm running into the
>>> issue of only internet explorer is refusing work. all the other browsers
>>> have no issues, reguardless of the OS. The login screen looks normal, post
>>> login looks like http://i.imgur.com/nwhGX88.png , and if I try to join
>>> straight to a meeting, all I get is that swirling icon in the middle of the
>>> screen, the one before the loading bar appears.
>>>
>>> The network is stuck behind a http proxy.
>>>
>>
>>
>>
>> --
>> WBR
>> Maxim aka solomax
>>
>
>

Re: Problems using via IE

Posted by William Overstreet <wi...@gmail.com>.
Thanks for that, was getting nailed with the Compatibility view. For some
reason corp says we need it turned on reasons. I guess I can edit the pages
to present the correct html to force non-compatibility view.


On Wed, Sep 10, 2014 at 10:42 PM, Maxim Solodovnik <so...@gmail.com>
wrote:

> can you check IE without proxy?
> can you check JS console in IE (F12 if I'm not mistaken)
> It seems jquery and/or some CSS files were not loaded (maybe because of
> proxy)
>
> On 11 September 2014 00:27, William Overstreet <
> william.ab.overstreet@gmail.com> wrote:
>
>> Trying to use openmeetings internally on our lan. I'm running into the
>> issue of only internet explorer is refusing work. all the other browsers
>> have no issues, reguardless of the OS. The login screen looks normal, post
>> login looks like http://i.imgur.com/nwhGX88.png , and if I try to join
>> straight to a meeting, all I get is that swirling icon in the middle of the
>> screen, the one before the loading bar appears.
>>
>> The network is stuck behind a http proxy.
>>
>
>
>
> --
> WBR
> Maxim aka solomax
>

Re: Problems using via IE

Posted by Maxim Solodovnik <so...@gmail.com>.
can you check IE without proxy?
can you check JS console in IE (F12 if I'm not mistaken)
It seems jquery and/or some CSS files were not loaded (maybe because of
proxy)

On 11 September 2014 00:27, William Overstreet <
william.ab.overstreet@gmail.com> wrote:

> Trying to use openmeetings internally on our lan. I'm running into the
> issue of only internet explorer is refusing work. all the other browsers
> have no issues, reguardless of the OS. The login screen looks normal, post
> login looks like http://i.imgur.com/nwhGX88.png , and if I try to join
> straight to a meeting, all I get is that swirling icon in the middle of the
> screen, the one before the loading bar appears.
>
> The network is stuck behind a http proxy.
>



-- 
WBR
Maxim aka solomax