- From: Daniel W. Connolly <connolly@beach.w3.org>
- Date: Wed, 20 Dec 1995 10:43:53 -0500
- To: Maciej Puzio <puzio@laser.mimuw.edu.pl>
- Cc: "'WWW Library Mailing List'" <www-lib@w3.org>
In message <01BACEEB.509B4760@pclab19.mimuw.edu.pl>, Maciej Puzio writes: >user clicks Cancel button in the dialog box? The file is not saved to the disk >, but the >message "Reading (2% of 3.8M)" still appears and changes slowly from 1% to 100 >%. >This really can lead to a deep confusion... > >Why's that? The library creates a stream stack to deal with the transmitted da >ta body >after parsing the MIME headers. In our example, the body is in the ZIP format, > so the >library decides that it should be saved to the disk (see HTConverterInit() in >HTInit.c). >It constructs then a HTSaveLocally stream using HTSaveLocally() function >(HTFWrite.c). This function prompts the user for a file name (via HTAlert). If > it gets >NULL (which means an error, e.g. click on Cancel button), the HTBlackHole is r >eturned >to the HTSaveLocally() caller. And instead of cancelling the connection, the d >ata keeps >flowing from the network and getting to the HTBlackHole, where it's discarded. > >Hmmm... > >The easiest solution is to change the result codes returned in >HTBlackHole_put_character, HTBlackHole_put_string and HTBlackHole_write >from HT_OK to HT_ERROR. Err... that would make the blackhole useless for its sole purpose: to consume the data. It seems like the problem is that the HTSaveLocally() uses the black hole in the first place -- it's not consuming the data, but rejecting it. If HTAlert fails, HTSaveLocally should return an error (or a new kinds of stream that reports HT_ERROR all the time), no? Dan
Received on Wednesday, 20 December 1995 10:44:14 UTC