W3C home > Mailing lists > Public > www-jigsaw@w3.org > July to August 1996

Incorrect content length

From: Jeff Dripps <jeff@macalot.com>
Date: Fri, 9 Aug 1996 16:42:08 -0400
Message-Id: <v01540b06ae314e191cde@[]>
To: www-jigsaw@w3.org


For several weeks I've been trying to track down the very last problem that
I've experienced getting Jigsaw to perform reliably on Macintosh. Antonio
Ramirez today gave me the missing piece of information that helped track it
down, while helping me with my simple filter question.

Here was my original problem:

Occasionally Jigsaw would send a file to the browser (Netscape) yet the
transfer would never complete, as though the browser expected more data,
yet Jigsaw indicated that the file transfer had completed. This would
*only* occur only on certain files. One such file that this problem could
be reproduced reliably 100% of the time is on:

At least on Macintosh when Jigsaw sends this file, the transfer would never
complete and with Antonio's help I believe I now know why. It appear that
Jigsaw is sometime miscalculating the content length of this document. To
demonstrate this, set up the HostURLFilter I sent up in an earlier message
on the Tutorials directory, but first add the following to the
ingoingFilter method:

String theContlen = new Integer (reply.getContentLength()).toString();

then add this to the end of the outgoing filter:

reply.setContentLength(strIS.available()) ;
String theNewContlen = new Integer (reply.getContentLength()).toString();

On my system the original (incorrect) content length comes back as 27065
while after filtering the correct content length returned is 26922. Also,
by adding the line setting the content length, the file is now transfered
without problem. Hope this helps. sinc, -jeff
Received on Friday, 9 August 1996 16:42:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:29 UTC