I've attached a gzip'd tar file with the sample. It was obtained with
the command I gave before:
telnet www.looksmart.com 80 > z1
GET / HTTP/1.1
Host: www.looksmart.comThe file "z1" is the unedited text captured from telnet. "z2" is the same file with the first 14 lines deleted (up to the chunk header "eca\r\n"). The first character of this file is the '<' in the "<html>" preamble. The file "z3" is a hex dump of z2, showing the byte offsets (16 bytes per line). In this case, with the chunk header "eca", the byte at offset 0xeca ought to be the CR. It is not, it is a data byte of the actual html page. (Bear in mind that the byte offsets in the dump are zero-based, but the chunk header starts counting from one, not zero!) There are no extraneous CRs or LFs in the intervening text to account for the extra byte, and presumably there are no added spaces or tabs either, but I cannot actually verify that case since I'm on the outside looking in. I have deleted apache-bugdb from the cc: list, presumably you don't want binary attachments showing up in your bug database. -- Howard [EMAIL PROTECTED] wrote: > Synopsis: First chunk body is too big, by one byte > > State-Changed-From-To: open-analyzed > State-Changed-By: marc > State-Changed-When: Tue Dec 9 17:55:33 PST 1997 > State-Changed-Why: > I'm afraid I can't see where this is happening. Are > you sure you are removing the last CR and LF properly? > Remember, if it ends in the middle of the line the > last CR and LF need to be removed. Some editors, > such as vi, do not allow you to do that. > > If you are certain that isn't happening, perhaps send > an example?
chunk.tar.gz
Description: GNU Zip compressed data
