It has no Content-Length header specified in the HTTP response.
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 78341 0 78341 0 0 139k 0 --:--:-- --:--:-- --:--:-- 193k
$ cat fid.header
HTTP/1.1 200 OK
Server: FWS/7.0
Content-Type: text/html;charset=UTF-8
Cache-Control: cache, must-revalidate
Expires: Tues, 01 Jan 1980 00:00:00 GMT
Pragma: no-cache
Fsreqid: REQ4f205ed80a04283020001001001baa33
Fscalleeid: fidweb411
Fselapsedtime: 5169
Date: Wed, 25 Jan 2012 19:58:16 GMT
Transfer-Encoding: chunked
Connection: keep-alive
Connection: Transfer-Encoding
Set-Cookie: HP_VER=C1; path=/; expires=Thu, 26-Jan-2012 19:58:16 GMT
Set-Cookie: v1st=C315B55A171791C5; path=/; expires=Wed, 19 Feb 2020 14:28:00 GMT; domain=.
fidelity.com
Set-Cookie: HttpOnly
Set-Cookie: JSESSIONID=B52AFB243713F2FCF39CF77DDE45838F; path=/pf/destination
Set-Cookie: MC=g^Og7t2FWVVtYQGUh1runkqsIDYSAk8gXtgKBCgwIAAQAQAdqjMGBAAAAQAGBU8gXtgAP03; path=/; domain=.
fidelity.com; expires=Thu, 24-Jan-2013 19:58:16 GMT
Set-Cookie: v1st=C315B55A171791C5; path=/; domain=.
fidelity.com; expires=Wed, 19 Feb 2020 14:28:00 GMT
Set-Cookie: v1st=C315B55A171791C5; path=/; domain=.
fidelity.com; expires=Wed, 19 Feb 2020 14:28:00 GMT
Even with HTTP/1.0
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 78334 0 78334 0 0 118k 0 --:--:-- --:--:-- --:--:-- 182k
$ cat fid.header
HTTP/1.0 200 OK
Server: FWS/7.0
Content-Type: text/html;charset=UTF-8
Cache-Control: cache, must-revalidate
Expires: Tues, 01 Jan 1980 00:00:00 GMT
Pragma: no-cache
Fsreqid: REQ4f205f110a022a3320001b2a0019aa33
Fscalleeid: fidweb221
Fselapsedtime: 7388
Date: Wed, 25 Jan 2012 19:59:13 GMT
Connection: close
Set-Cookie: HP_VER=C1; path=/; expires=Thu, 26-Jan-2012 19:59:13 GMT
Set-Cookie: v1st=87929215BDF1851; path=/; expires=Wed, 19 Feb 2020 14:28:00 GMT; domain=.
fidelity.comSet-Cookie: HttpOnly
Set-Cookie: JSESSIONID=8F7DDEFFE75CA872A9881AFDCA018C2F; path=/pf/destination
Set-Cookie: MC=8xxvSOBpbhzzUtG8x3VeBR7H^sQSAk8gXxEKAiozIAAbKgAbqjMGBAAAAQAGBU8gXxEAP03; path=/; domain=.
fidelity.com; expires=Thu, 24-Jan-2013 19:59:13 GMT
Set-Cookie: v1st=87929215BDF1851; path=/; domain=.
fidelity.com; expires=Wed, 19 Feb 2020 14:28:00 GMT
Set-Cookie: v1st=87929215BDF1851; path=/; domain=.
fidelity.com; expires=Wed, 19 Feb 2020 14:28:00 GMT
--
Joakim Erdfelt
(the people behind jetty and cometd)
On Wed, Jan 25, 2012 at 12:47 PM, Chris Dumoulin
<chris@xxxxxxxx> wrote:
I've noticed a difference in behaviour from Jetty HttpClient version
7.2.0 to 7.5.4 when a web server indicates a Content-Length, sends
back some data (but not the full amount) and then closes the
connection. With version 7.2.0 onException() wouldn't be called and
onResponseComplete() would, but in 7.5.4 onException() gets called
but not onResponseComplete(). Note that this only seems to happen
when using HTTP 1.0 with the HttpClient.
Is this change in behaviour expected? Which is the correct
behaviour? I see this in the the HTTP spec (
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html):
"
When
a Content-Length is given in a message where a message-body is
allowed, its field value MUST exactly match the number of OCTETs
in the message-body. HTTP/1.1 user agents MUST notify the user
when an invalid length is received and detected."
However, browsers seem to handle the situation without an error.
https://www.fidelity.com is an example of a web page that sets the
Content-Length but doesn't send the full amount.
I've attached a test program that I was using to reproduce this.
Thanks,
Chris
_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-users