- From: Joe Pallas <pallas@apple.com>
- Date: 29 Jul 96 17:42:37 -0700
- To: "www-lib-bugs@w3.org"<www-lib-bugs@w3.org>
Here are a few things I've encountered using the 4.1b1 release of the library: In HTStreamStack, if the input and output formats are the same and there's no output stream, it returns an error stream. I believe it makes more sense to return HTBlackHole(), since it isn't really an error. [This situation arose from doing a HEAD operation, with rfc822 as the input/output format.] In HTMIME_putblock, the last character of the header gets treated as data (someone else already reported this, I believe). Also, the code at the end behaves badly if there is no target (which happens if there's no content-type field). I suggest adding "if (l > 0 && !me->target) return HT_ERROR;" before the "put the rest down the stream" code, and checking for l>0 before calling put_block on the target. [This situation arose when a server treated HEAD as if it were GET.] In the HTNet delete_object routine, the HTChannel_downSemaphore call should come before the HTChannel_delete, or else the delete won't delete the channel. I found I was not reusing sockets because of this. In HTReader.c, the definition of _HTInputStream doesn't match the definition in HTANSI.c. The "FILE *fp" field is missing. I'm not sure if this is a real bug or not, but I think it is, and it certainly confused my debugger. In HTRules.c, the last line doesn't get parsed. I added "HTRule_parseLine(rules, HTChunk_data(me->buffer));" to HTRule_free to process the remaining data. I hope this input is useful. joe -- Joe Pallas Apple Research Laboratories
Received on Monday, 29 July 1996 20:42:52 UTC