<script src="<c:url value="/scripts/dwr/engine.js"/>" type="text/javascript"></script>

Why are you not serving engine.js from the DWR Servlet?

"there is also a hard coded path to '/servlet1/' in the variable "_pathToDwrServlet" - is this adjustable in the config XML?"
Yes, see overridePath - http://directwebremoting.org/dwr/documentation/server/configuration/servlet/index.html

You can also modify this in your interface js,  Interface._path = 'http://yourpath/dwr'; But I am not sure either of these options is the correct approach.

I am curious how this was working in 2.x so I will be looking into it.

On 12/1/2010 4:11 AM, Paul Barrett wrote:

Hi All,

 
 We've been using DWR 2.0.5 with the following Spring based configuration:
 
 web.xml: servlet definition
 <servlet>
   <servlet-name>dwr-invoker</servlet-name>
   <servlet-class>org.directwebremoting.spring.DwrSpringServlet</servlet-class>
   <init-param>
      <param-name>debug</param-name>
        <param-value>true</param-value>
   </init-param>
   <init-param>
     <param-name>allowScriptTagRemoting</param-name>
        <param-value>true</param-value>
   </init-param>
 </servlet>
 
 
 web.xml: servlet mapping for multiple servlets - we need this as different servlets require different authentication privileges. We use specific filters on each servlet to authenticate the user to make sure they have access; thus the DWR must be relative to these servlets so the filter is invoked.
 <servlet-mapping>
    <servlet-name>dwr-invoker</servlet-name>
    <url-pattern>/serlvet1/dwr/*</url-pattern>
  </servlet-mapping>
  <servlet-mapping>
    <servlet-name>serlvet1</servlet-name>
    <url-pattern>/serlvet1/*</url-pattern>
  </servlet-mapping>
  <servlet-mapping>
    <servlet-name>dwr-invoker</servlet-name>
    <url-pattern>/serlvet2/dwr/*</url-pattern>
  </servlet-mapping>
  <servlet-mapping>
    <servlet-name>serlvet2</servlet-name>
    <url-pattern>/serlvet2/*</url-pattern>
 </servlet-mapping>
 
 jsp template: we add the DWR-generated client javascript with a relative path (no root '/').
 <script src="<c:url value="/scripts/dwr/engine.js"/>" type="text/javascript"></script>
 <script src="<c:url value="dwr/util.js"/>" type="text/javascript"></script>
 <script src="<c:url value="dwr/interface/MyClass1.js"/>" type="text/javascript" charset="utf-8"></script>
 <script src="<c:url value="dwr/interface/MyCLass2.js"/>" type="text/javascript" charset="utf-8"></script>
 
 Since upgrading to 3rc1 we have encountered a problem we have now is that the DWR-generated client javascript _path is always '/servlet1/' where in 2.0.5 it was the servlet path of the current context.
 
 So, some questions:
 
  - Is this a bug?
  - How can we get the behaviour back to that of 2.0.5?
  - How is engine.js generated - there is also a hard coded path to '/servlet1/' in the variable "_pathToDwrServlet" - is this adjustable in the config XML?
  - Is there a better configuration for the scenario that we require?


  Cheers,
  Paul

Ok, so thinking about this a bit more:

<script src="<c:url value="/scripts/dwr/engine.js"/>" type="text/javascript"></script>

throws up a big red flag.  What this says to me is that you are saving off engine.js.  This will only work (out of the box without resetting the path through JavaScript) from the context in which you saved engine.js.  So unless you have two saved engine.js files (one for each context), I don't see how this was working.  Are you certain you were doing this in 2.x?

The _pathToDwrServlet is not hard coded.  It is replaced with the Servlet's context path when the DWR servlet serves engine.js.  There is no reason to cache off engine.js (as of 3), so change your include to:
<script src="<c:url value="dwr/engine.js"/>" type="text/javascript" charset="utf-8"></script>

and my guess is that all should be well.

-David

On Wed, Dec 1, 2010 at 6:31 AM, David Marginian <david <at> butterdev.com> wrote:

<script src="<c:url value="/scripts/dwr/engine.js"/>" type="text/javascript"></script>

Why are you not serving engine.js from the DWR Servlet?

"there is also a hard coded path to '/servlet1/' in the variable "_pathToDwrServlet" - is this adjustable in the config XML?"
Yes, see overridePath - http://directwebremoting.org/dwr/documentation/server/configuration/servlet/index.html

You can also modify this in your interface js,  Interface._path = 'http://yourpath/dwr'; But I am not sure either of these options is the correct approach.

I am curious how this was working in 2.x so I will be looking into it.

On 12/1/2010 4:11 AM, Paul Barrett wrote:

Hi All,

 
 We've been using DWR 2.0.5 with the following Spring based configuration:
 
 web.xml: servlet definition
 <servlet>
   <servlet-name>dwr-invoker</servlet-name>
   <servlet-class>org.directwebremoting.spring.DwrSpringServlet</servlet-class>
   <init-param>
      <param-name>debug</param-name>
        <param-value>true</param-value>
   </init-param>
   <init-param>
     <param-name>allowScriptTagRemoting</param-name>
        <param-value>true</param-value>
   </init-param>
 </servlet>
 
 
 web.xml: servlet mapping for multiple servlets - we need this as different servlets require different authentication privileges. We use specific filters on each servlet to authenticate the user to make sure they have access; thus the DWR must be relative to these servlets so the filter is invoked.
 <servlet-mapping>
    <servlet-name>dwr-invoker</servlet-name>
    <url-pattern>/serlvet1/dwr/*</url-pattern>
  </servlet-mapping>
  <servlet-mapping>
    <servlet-name>serlvet1</servlet-name>
    <url-pattern>/serlvet1/*</url-pattern>
  </servlet-mapping>
  <servlet-mapping>
    <servlet-name>dwr-invoker</servlet-name>
    <url-pattern>/serlvet2/dwr/*</url-pattern>
  </servlet-mapping>
  <servlet-mapping>
    <servlet-name>serlvet2</servlet-name>
    <url-pattern>/serlvet2/*</url-pattern>
 </servlet-mapping>
 
 jsp template: we add the DWR-generated client javascript with a relative path (no root '/').
 <script src="<c:url value="/scripts/dwr/engine.js"/>" type="text/javascript"></script>
 <script src="<c:url value="dwr/util.js"/>" type="text/javascript"></script>
 <script src="<c:url value="dwr/interface/MyClass1.js"/>" type="text/javascript" charset="utf-8"></script>
 <script src="<c:url value="dwr/interface/MyCLass2.js"/>" type="text/javascript" charset="utf-8"></script>
 
 Since upgrading to 3rc1 we have encountered a problem we have now is that the DWR-generated client javascript _path is always '/servlet1/' where in 2.0.5 it was the servlet path of the current context.
 
 So, some questions:
 
  - Is this a bug?
  - How can we get the behaviour back to that of 2.0.5?
  - How is engine.js generated - there is also a hard coded path to '/servlet1/' in the variable "_pathToDwrServlet" - is this adjustable in the config XML?
  - Is there a better configuration for the scenario that we require?


  Cheers,
  Paul

Hi David,

Thanks for your help so far. We were using a static engine.js for performance reasons after we'd seen a few articles demonstrating this.

We changed it to point to the dynamic engine.js but still had the same problem.

After seeing that you could use the overridePath in the servlet config, I tried the following out of curiosity:

      <init-param>
           <param-name>overridePath</param-name>
           <param-value>dwr/</param-value>
      </init-param>

This approach works for us - it always picks up the current context path and no longer produces authentication warnings. This may be of use to you as I see that others have had similar problems. We can't work out what change would have caused this to happen between 2.0.5 and 3rc1.

Out of interest, would you do the DWR configuration any differently with our scenario?

 

We've just been looking at the dwr:filter and how we could bind our security filter using that rather than via the servlet filter. Would that give us any benefit over our current configuration approach?

Thanks again.
Paul

On 1 December 2010 14:01, David Marginian <david <at> butterdev.com> wrote:

Ok, so thinking about this a bit more:

<script src="<c:url value="/scripts/dwr/engine.js"/>" type="text/javascript"></script>

throws up a big red flag.  What this says to me is that you are saving off engine.js.  This will only work (out of the box without resetting the path through JavaScript) from the context in which you saved engine.js.  So unless you have two saved engine.js files (one for each context), I don't see how this was working.  Are you certain you were doing this in 2.x?

The _pathToDwrServlet is not hard coded.  It is replaced with the Servlet's context path when the DWR servlet serves engine.js.  There is no reason to cache off engine.js (as of 3), so change your include to:
<script src="<c:url value="dwr/engine.js"/>" type="text/javascript" charset="utf-8"></script>

and my guess is that all should be well.

-David

On Wed, Dec 1, 2010 at 6:31 AM, David Marginian <david <at> butterdev.com> wrote:

<script src="<c:url value="/scripts/dwr/engine.js"/>" type="text/javascript"></script>

Why are you not serving engine.js from the DWR Servlet?

"there is also a hard coded path to '/servlet1/' in the variable "_pathToDwrServlet" - is this adjustable in the config XML?"
Yes, see overridePath - http://directwebremoting.org/dwr/documentation/server/configuration/servlet/index.html

You can also modify this in your interface js,  Interface._path = 'http://yourpath/dwr'; But I am not sure either of these options is the correct approach.

I am curious how this was working in 2.x so I will be looking into it.

On 12/1/2010 4:11 AM, Paul Barrett wrote:

Hi All,

 
 We've been using DWR 2.0.5 with the following Spring based configuration:
 
 web.xml: servlet definition
 <servlet>
   <servlet-name>dwr-invoker</servlet-name>
   <servlet-class>org.directwebremoting.spring.DwrSpringServlet</servlet-class>
   <init-param>
      <param-name>debug</param-name>
        <param-value>true</param-value>
   </init-param>
   <init-param>
     <param-name>allowScriptTagRemoting</param-name>
        <param-value>true</param-value>
   </init-param>
 </servlet>
 
 
 web.xml: servlet mapping for multiple servlets - we need this as different servlets require different authentication privileges. We use specific filters on each servlet to authenticate the user to make sure they have access; thus the DWR must be relative to these servlets so the filter is invoked.
 <servlet-mapping>
    <servlet-name>dwr-invoker</servlet-name>
    <url-pattern>/serlvet1/dwr/*</url-pattern>
  </servlet-mapping>
  <servlet-mapping>
    <servlet-name>serlvet1</servlet-name>
    <url-pattern>/serlvet1/*</url-pattern>
  </servlet-mapping>
  <servlet-mapping>
    <servlet-name>dwr-invoker</servlet-name>
    <url-pattern>/serlvet2/dwr/*</url-pattern>
  </servlet-mapping>
  <servlet-mapping>
    <servlet-name>serlvet2</servlet-name>
    <url-pattern>/serlvet2/*</url-pattern>
 </servlet-mapping>
 
 jsp template: we add the DWR-generated client javascript with a relative path (no root '/').
 <script src="<c:url value="/scripts/dwr/engine.js"/>" type="text/javascript"></script>
 <script src="<c:url value="dwr/util.js"/>" type="text/javascript"></script>
 <script src="<c:url value="dwr/interface/MyClass1.js"/>" type="text/javascript" charset="utf-8"></script>
 <script src="<c:url value="dwr/interface/MyCLass2.js"/>" type="text/javascript" charset="utf-8"></script>
 
 Since upgrading to 3rc1 we have encountered a problem we have now is that the DWR-generated client javascript _path is always '/servlet1/' where in 2.0.5 it was the servlet path of the current context.
 
 So, some questions:
 
  - Is this a bug?
  - How can we get the behaviour back to that of 2.0.5?
  - How is engine.js generated - there is also a hard coded path to '/servlet1/' in the variable "_pathToDwrServlet" - is this adjustable in the config XML?
  - Is there a better configuration for the scenario that we require?


  Cheers,
  Paul

"We were using a static engine.js for performance reasons after we'd seen a few articles demonstrating this."

This only applies to 2.x.  In 2.x there was a section of engine.js that was dynamic and therefore engine.js could not be cached.  That no longer applies to version 3.x.

"We changed it to point to the dynamic engine.js but still had the same problem."

I wonder if this is related to caching.  Is the path always set to the first context that was hit?  Can you verify this?  I would like to be able to isolate what is going on and since you have the environment set-up this would be helpful to us.

"Out of interest, would you do the DWR configuration any differently with our scenario?"

This doesn't seem like the best way to do it, but I would have to look into it in more detail.  Someone else on the list with more experience with this sort of set-up may be able to help.

On Wed, Dec 1, 2010 at 8:05 AM, Paul Barrett <barrettuberalles-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

Hi David,

Thanks for your help so far. We were using a static engine.js for performance reasons after we'd seen a few articles demonstrating this.

We changed it to point to the dynamic engine.js but still had the same problem.

After seeing that you could use the overridePath in the servlet config, I tried the following out of curiosity:

      <init-param>
           <param-name>overridePath</param-name>
           <param-value>dwr/</param-value>
      </init-param>

This approach works for us - it always picks up the current context path and no longer produces authentication warnings. This may be of use to you as I see that others have had similar problems. We can't work out what change would have caused this to happen between 2.0.5 and 3rc1.

Out of interest, would you do the DWR configuration any differently with our scenario?

 

We've just been looking at the dwr:filter and how we could bind our security filter using that rather than via the servlet filter. Would that give us any benefit over our current configuration approach?

Thanks again.
Paul

On 1 December 2010 14:01, David Marginian <david <at> butterdev.com> wrote:

Ok, so thinking about this a bit more:

<script src="<c:url value="/scripts/dwr/engine.js"/>" type="text/javascript"></script>

throws up a big red flag.  What this says to me is that you are saving off engine.js.  This will only work (out of the box without resetting the path through JavaScript) from the context in which you saved engine.js.  So unless you have two saved engine.js files (one for each context), I don't see how this was working.  Are you certain you were doing this in 2.x?

The _pathToDwrServlet is not hard coded.  It is replaced with the Servlet's context path when the DWR servlet serves engine.js.  There is no reason to cache off engine.js (as of 3), so change your include to:
<script src="<c:url value="dwr/engine.js"/>" type="text/javascript" charset="utf-8"></script>

and my guess is that all should be well.

-David

On Wed, Dec 1, 2010 at 6:31 AM, David Marginian <david <at> butterdev.com> wrote:

<script src="<c:url value="/scripts/dwr/engine.js"/>" type="text/javascript"></script>

Why are you not serving engine.js from the DWR Servlet?

"there is also a hard coded path to '/servlet1/' in the variable "_pathToDwrServlet" - is this adjustable in the config XML?"
Yes, see overridePath - http://directwebremoting.org/dwr/documentation/server/configuration/servlet/index.html

You can also modify this in your interface js,  Interface._path = 'http://yourpath/dwr'; But I am not sure either of these options is the correct approach.

I am curious how this was working in 2.x so I will be looking into it.

On 12/1/2010 4:11 AM, Paul Barrett wrote:

Hi All,

 
 We've been using DWR 2.0.5 with the following Spring based configuration:
 
 web.xml: servlet definition
 <servlet>
   <servlet-name>dwr-invoker</servlet-name>
   <servlet-class>org.directwebremoting.spring.DwrSpringServlet</servlet-class>
   <init-param>
      <param-name>debug</param-name>
        <param-value>true</param-value>
   </init-param>
   <init-param>
     <param-name>allowScriptTagRemoting</param-name>
        <param-value>true</param-value>
   </init-param>
 </servlet>
 
 
 web.xml: servlet mapping for multiple servlets - we need this as different servlets require different authentication privileges. We use specific filters on each servlet to authenticate the user to make sure they have access; thus the DWR must be relative to these servlets so the filter is invoked.
 <servlet-mapping>
    <servlet-name>dwr-invoker</servlet-name>
    <url-pattern>/serlvet1/dwr/*</url-pattern>
  </servlet-mapping>
  <servlet-mapping>
    <servlet-name>serlvet1</servlet-name>
    <url-pattern>/serlvet1/*</url-pattern>
  </servlet-mapping>
  <servlet-mapping>
    <servlet-name>dwr-invoker</servlet-name>
    <url-pattern>/serlvet2/dwr/*</url-pattern>
  </servlet-mapping>
  <servlet-mapping>
    <servlet-name>serlvet2</servlet-name>
    <url-pattern>/serlvet2/*</url-pattern>
 </servlet-mapping>
 
 jsp template: we add the DWR-generated client javascript with a relative path (no root '/').
 <script src="<c:url value="/scripts/dwr/engine.js"/>" type="text/javascript"></script>
 <script src="<c:url value="dwr/util.js"/>" type="text/javascript"></script>
 <script src="<c:url value="dwr/interface/MyClass1.js"/>" type="text/javascript" charset="utf-8"></script>
 <script src="<c:url value="dwr/interface/MyCLass2.js"/>" type="text/javascript" charset="utf-8"></script>
 
 Since upgrading to 3rc1 we have encountered a problem we have now is that the DWR-generated client javascript _path is always '/servlet1/' where in 2.0.5 it was the servlet path of the current context.
 
 So, some questions:
 
  - Is this a bug?
  - How can we get the behaviour back to that of 2.0.5?
  - How is engine.js generated - there is also a hard coded path to '/servlet1/' in the variable "_pathToDwrServlet" - is this adjustable in the config XML?
  - Is there a better configuration for the scenario that we require?


  Cheers,
  Paul

I can verify this, yes.

Without adding the overridePath and with the servlet configs described earlier, hitting a page in the servlet1 context generates an engine.js file. Navigating to /servlet1/dwr/engine.js, the file contains:

dwr.engine._pathToDwrServlet = "/servlet1/dwr/";

Navigating from there to a page in the servlet2 context (which does not have privileges to view servlet1 content), then to /servlet2/dwr/engine.js, the file still contains:

dwr.engine._pathToDwrServlet = "/servlet1/dwr/";

which causes a security exception in our server-side code.

Adding the overridePath of dwr (or dwr/) fixes the problem - /servlet2/dwr/engine.js contains:

dwr.engine._pathToDwrServlet = "dwr";

All requests for converted objects use the correct context - in servlet2 context using fiebug in Firefox they are displayed as /servlet2/dwr/call/plaincall/MyClass.methodName.dwr

If you need more info let me know, I hope this is of some use.

Thanks
Paul

On 1 December 2010 15:19, David Marginian <david-H55tQ8LTKd1xxXtqJ93Y6g@public.gmane.org> wrote:

"We were using a static engine.js for performance reasons after we'd seen a few articles demonstrating this."

This only applies to 2.x.  In 2.x there was a section of engine.js that was dynamic and therefore engine.js could not be cached.  That no longer applies to version 3.x.

"We changed it to point to the dynamic engine.js but still had the same problem."

I wonder if this is related to caching.  Is the path always set to the first context that was hit?  Can you verify this?  I would like to be able to isolate what is going on and since you have the environment set-up this would be helpful to us.

"Out of interest, would you do the DWR configuration any differently with our scenario?"

This doesn't seem like the best way to do it, but I would have to look into it in more detail.  Someone else on the list with more experience with this sort of set-up may be able to help.

On Wed, Dec 1, 2010 at 8:05 AM, Paul Barrett <barrettuberalles-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

Hi David,

Thanks for your help so far. We were using a static engine.js for performance reasons after we'd seen a few articles demonstrating this.

We changed it to point to the dynamic engine.js but still had the same problem.

After seeing that you could use the overridePath in the servlet config, I tried the following out of curiosity:

      <init-param>
           <param-name>overridePath</param-name>
           <param-value>dwr/</param-value>
      </init-param>

This approach works for us - it always picks up the current context path and no longer produces authentication warnings. This may be of use to you as I see that others have had similar problems. We can't work out what change would have caused this to happen between 2.0.5 and 3rc1.

Out of interest, would you do the DWR configuration any differently with our scenario?

 

We've just been looking at the dwr:filter and how we could bind our security filter using that rather than via the servlet filter. Would that give us any benefit over our current configuration approach?

Thanks again.
Paul

On 1 December 2010 14:01, David Marginian <david <at> butterdev.com> wrote:

Ok, so thinking about this a bit more:

<script src="<c:url value="/scripts/dwr/engine.js"/>" type="text/javascript"></script>

throws up a big red flag.  What this says to me is that you are saving off engine.js.  This will only work (out of the box without resetting the path through JavaScript) from the context in which you saved engine.js.  So unless you have two saved engine.js files (one for each context), I don't see how this was working.  Are you certain you were doing this in 2.x?

The _pathToDwrServlet is not hard coded.  It is replaced with the Servlet's context path when the DWR servlet serves engine.js.  There is no reason to cache off engine.js (as of 3), so change your include to:
<script src="<c:url value="dwr/engine.js"/>" type="text/javascript" charset="utf-8"></script>

and my guess is that all should be well.

-David

On Wed, Dec 1, 2010 at 6:31 AM, David Marginian <david <at> butterdev.com> wrote:

<script src="<c:url value="/scripts/dwr/engine.js"/>" type="text/javascript"></script>

Why are you not serving engine.js from the DWR Servlet?

"there is also a hard coded path to '/servlet1/' in the variable "_pathToDwrServlet" - is this adjustable in the config XML?"
Yes, see overridePath - http://directwebremoting.org/dwr/documentation/server/configuration/servlet/index.html

You can also modify this in your interface js,  Interface._path = 'http://yourpath/dwr'; But I am not sure either of these options is the correct approach.

I am curious how this was working in 2.x so I will be looking into it.

On 12/1/2010 4:11 AM, Paul Barrett wrote:

Hi All,

 
 We've been using DWR 2.0.5 with the following Spring based configuration:
 
 web.xml: servlet definition
 <servlet>
   <servlet-name>dwr-invoker</servlet-name>
   <servlet-class>org.directwebremoting.spring.DwrSpringServlet</servlet-class>
   <init-param>
      <param-name>debug</param-name>
        <param-value>true</param-value>
   </init-param>
   <init-param>
     <param-name>allowScriptTagRemoting</param-name>
        <param-value>true</param-value>
   </init-param>
 </servlet>
 
 
 web.xml: servlet mapping for multiple servlets - we need this as different servlets require different authentication privileges. We use specific filters on each servlet to authenticate the user to make sure they have access; thus the DWR must be relative to these servlets so the filter is invoked.
 <servlet-mapping>
    <servlet-name>dwr-invoker</servlet-name>
    <url-pattern>/serlvet1/dwr/*</url-pattern>
  </servlet-mapping>
  <servlet-mapping>
    <servlet-name>serlvet1</servlet-name>
    <url-pattern>/serlvet1/*</url-pattern>
  </servlet-mapping>
  <servlet-mapping>
    <servlet-name>dwr-invoker</servlet-name>
    <url-pattern>/serlvet2/dwr/*</url-pattern>
  </servlet-mapping>
  <servlet-mapping>
    <servlet-name>serlvet2</servlet-name>
    <url-pattern>/serlvet2/*</url-pattern>
 </servlet-mapping>
 
 jsp template: we add the DWR-generated client javascript with a relative path (no root '/').
 <script src="<c:url value="/scripts/dwr/engine.js"/>" type="text/javascript"></script>
 <script src="<c:url value="dwr/util.js"/>" type="text/javascript"></script>
 <script src="<c:url value="dwr/interface/MyClass1.js"/>" type="text/javascript" charset="utf-8"></script>
 <script src="<c:url value="dwr/interface/MyCLass2.js"/>" type="text/javascript" charset="utf-8"></script>
 
 Since upgrading to 3rc1 we have encountered a problem we have now is that the DWR-generated client javascript _path is always '/servlet1/' where in 2.0.5 it was the servlet path of the current context.
 
 So, some questions:
 
  - Is this a bug?
  - How can we get the behaviour back to that of 2.0.5?
  - How is engine.js generated - there is also a hard coded path to '/servlet1/' in the variable "_pathToDwrServlet" - is this adjustable in the config XML?
  - Is there a better configuration for the scenario that we require?


  Cheers,
  Paul

Attached pic shows 3 active IE6 DWR connections (all reverse ajax), there are another 3 forward ajax connections which are short lived (not shown in this picture).

The pic also shows registry: using proxy, and default connection limits.

 

发件人: Mike Wilson [mailto:mikewse-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org]
发送时间: Wednesday, December 01, 2010 1:11 AM
收件人: users-EyPigyGktj4FDOXUYO6UHQ@public.gmane.org
主题: RE: [dwr-user] HTTP Connection limitation with proxy server

 

I retested in my test VM for IE7 and for me IE enforces a two connection limit for all sites going through the proxy server. This is an easy test that doesn't involve Reverse Ajax or DWR:

1. Surf to external site1 and start downloading a large file that will take a while before finishing.
2. Start one more large download from site1.
3. Now surf to site2 in a separate tab. If it is displays promptly, then you have three connections active to the proxy server. If site2 is hanging and keeping you waiting then you have hit the two connection limit. Cancelling one of the downloads will free up one connection to the proxy server and allow site2 to load.

My IE7 installation is a completely default installation, the only action taken after installation is running Windows Update and setting the proxy server option, and it exhibits the hanging behaviour in (3). I've also had the same experience in several corporate intranets over the years.

It'd be great to know why it is working differently for you? What happens if you try to open six connections to the same external site?

 

Best regards

Mike

 

From: Jeff Ma [mailto:jeff.ma-WP3DaA1RUiz6V6G2DxALlg@public.gmane.org]
Sent: den 30 november 2010 13:37
To: users-EyPigyGktj4FDOXUYO6UHQ@public.gmane.org
Subject: RE: [dwr-user] HTTP Connection limitation with proxy server

Yes.

 

发件人: Mike Wilson [mailto:mikewse-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org]
发送时间: Tuesday, November 30, 2010 5:14 PM
收件人: users-EyPigyGktj4FDOXUYO6UHQ@public.gmane.org
主题: RE: [dwr-user] HTTP Connection limitation with proxy server

 

Very interesting, as this is the opposite of what I've seen before

And all those six connections are to the same host (the proxy server) ?

 

Best regards

Mike

 

Jeff Ma wrote:

 

HTTP 1.1. Also there are moments when 6 connections are available. Two connections for each domain.

 

发件人: Mike Wilson [mailto:mikewse-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org]
发送时间: Tuesday, November 30, 2010 2:26 PM
收件人: users-EyPigyGktj4FDOXUYO6UHQ@public.gmane.org
主题: RE: [dwr-user] HTTP Connection limitation with proxy server

 

Jeff, could you check if the proxy is using HTTP 1.0 or 1.1? Inspect the responses from Java or sniff the requests with Fiddler. On HTTP 1.0 the recommendation is four connections so it could be that you are seeing.

 

Best regards

Mike

 

Jeff Ma wrote:

 

Hi Mike and all,

 

We used the Microsoft tool and verified that IE6 can support 3 connections with proxy.

We have only one proxy server, and verified that we didn’t modify the registry to increase IE connection limit.

IE6/IE7 was able to simultaneously connect to 3 domains through one proxy server. That’s mean using proxy server will not add connections to different domains, which is great news for all long-live ajax apps!

 

Regards,

-          jeff

 

发件人: Mike Wilson [mailto:mikewse-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org]
发送时间: Monday, November 29, 2010 4:46 PM
收件人: users-EyPigyGktj4FDOXUYO6UHQ@public.gmane.org
主题: RE: [dwr-user] HTTP Connection limitation with proxy server

 

Hi Jeff,

AFAIK this problem affects both IE6 and IE7. Your mileage may vary though, because some organisations distribute their connections over a farm of proxy servers and you get two connections to each. Seeing is believing though, so examine what connections are actually made with some network sniffing tool. On Windows it is quite convenient to use Sysinternals Tcpview

http://technet.microsoft.com/en-us/sysinternals/bb897437.aspx

as it will display active connections in real time. Just fire it up, maybe filter on the process iexplore.exe, and then surf to your sites from IE.

Don't forget to report back with your findings, we are always interested to hear about how different environments behave.

Best regards

Mike

 

From: Jeff Ma [mailto:jeff.ma-WP3DaA1RUiz6V6G2DxALlg@public.gmane.org]
Sent: den 29 november 2010 06:39
To: users-EyPigyGktj4FDOXUYO6UHQ@public.gmane.org
Subject: [dwr-user] HTTP Connection limitation with proxy server

Hi Mike and all,

 

We tested with Apache proxy server and IE7. In 3 IE7 tabs, we connect to 3 domains (abc1.com, abc2.com and abc3.com), each URL has 1 reverse ajax + 1 forward ajax connection. The test result is: all 3 URL works fine without connection limit issue. It seems IE7 consider each domain as unique domain, instead of common domain as you referred to below. We also tested with IE6, no problems either.

 

Is there a special proxy server type (or setting) that can cause browser consider all connection as common connection?

 

Any comments are appreciated.

 

Regards,

-          Jeff Ma

 

发件人: Mike Wilson [mailto:mikewse-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org]
发送时间: Thursday, October 14, 2010 2:34 AM
收件人: users-EyPigyGktj4FDOXUYO6UHQ@public.gmane.org
主题: RE: [dwr-user] HTTP Connection limitation

On Tue, Oct 12, 2010 at 12:52 PM, Mike Wilson <mikewse <at> hotmail.com> wrote:

Adding to David's answer, the HTTP specs actually recommend limits of two (HTTP 1.1) and four (HTTP 1.0) connections per remote host.

If you're behind a proxy server you should be aware that this often means all remote sites share a common connection limit, to the proxy server.

 

Best regards

Mike Wilson

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe-EyPigyGktj4FDOXUYO6UHQ@public.gmane.org
For additional commands, e-mail: users-help-EyPigyGktj4FDOXUYO6UHQ@public.gmane.org