[Prev][Next][Index][Thread]

Re: HTBlackHole problem & dealing with stream return codes in HTTee



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


References: