Clients: Internet Explorer 8, Google Chrome 17.0.963, Silverlight 4.0 in ClientHttp mode
Rough content information: HTTP/1.1 200 OK Accept-Ranges: bytes Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept Content-Length: 30636 Content-Type: text/plain; charset=UTF-8 In this case, data received before stopping was around 16421. (looking only at body) HTTP/1.1 200 OK Accept-Ranges: bytes Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept Content-Length: 191395 Content-Type: text/plain; charset=UTF-8 In this case, rough data received before stopping was around 183019. (looking only at body) The response is raw XML data. It is not compressed in any way. It is a single REST style HTTP/1.1 GET call, though a favicon download occurs following making this call through internet explorer or chrome and Silverlight performs a preceding download of XML files for client access policy and cross domain policy. Multiple tests were performed between different sets of machines, with connections between the two including: 22/5 Cable connection (with VPN overhead) 12/3 Cable connection (with VPN overhead) Loopback (performed GET from the same server hosting the running Jetty) Tomorrow I will have the chance to perform some tests over a 10/100 LAN in place of the VPN. On Thu, Feb 23, 2012 at 23:02, Joakim Erdfelt <[email protected]> wrote: > Can you tell us a bit about the conditions of this? > We'd like to setup a unit test to attempt to replicate it. > > What kind of client? > What is the size of the content? > Is the response gzip'd? > Is this large content part of a HTTP/1.1 pipeline request chain? > What speed is the network connection? (such as wired 1gbit / wifi g / 4g / > 3g / edge / 14.4k modem, etc...) > > -- > Joakim Erdfelt > [email protected] > > http://webtide.com | http://intalio.com > (the people behind jetty and cometd) > > > > On Thu, Feb 23, 2012 at 8:02 PM, Michael Henderson <[email protected]> > wrote: >> >> I've been working on a REST solution that makes use of an embedded >> Jetty instance (specifically Restlet). Currently, the framework's >> built in extension for Jetty support only up to version 7.4.2 due to >> some class name and package changes (HttpConnection -> >> AbstractHttpConnection, the change of the preferred SslContextFactory >> to being that in org.eclipse.jetty.util.ssl rather than >> org.eclipse.jetty.http.ssl). >> >> Therefore, I have been looking to create a connector based off the >> existing that I can keep up to date with newest Jetty versions. >> >> I encountered little trouble until I began wider testing, and found >> that with either Jetty 7.6.1 or Jetty 8.1.1 in use, certain requests >> whose responses were large enough to exceed a single packet/buffer >> size, would fail to ever receive the final response packet. The >> responses would be cut off at the same point each time in these larger >> responses. (to the exact same byte each time) >> >> To further confuse this issue, the cut off would occur differently on >> different machines, and for a few machines it would not occur >> whatsoever. It does not appear to be browser or operating system >> dependent (though they only ones I test with at this early stage are >> IE8 and Google Chrome, and Windows 7 varieties). >> >> I am trying to determine what could have changed in the response >> behavior of Jetty between versions 7.4 and 7.6 that could cause such a >> failure. The connection appears to simply idle out rather than >> providing the final packet needed. The behavior for the REST >> application interacting with the Jetty instance has not changed >> outside of the renaming mentioned above, so I expect there is >> something new that needs to be done to properly provide a response. >> >> Any insight that could be provided would be appreciated, as my >> knowledge of Jetty is quite limited. >> _______________________________________________ >> jetty-users mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/jetty-users > > > > _______________________________________________ > jetty-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/jetty-users > _______________________________________________ jetty-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/jetty-users
