Please see here https://github.com/whatwg/streams/issues/33, I realized
that this would apply to operations like textDecoder too without the
need of an explicit stream option, so that's no more WebCrypto only related.
Regards
Aymeric
Le 07/11/2013 11:25, Aymeric Vitte a écrit :
Le 07/11/2013 10:42, Takeshi Yoshino a écrit :
On Thu, Nov 7, 2013 at 6:27 PM, Aymeric Vitte <[email protected]
<mailto:[email protected]>> wrote:
Le 07/11/2013 10:21, Takeshi Yoshino a écrit :
On Thu, Nov 7, 2013 at 6:05 PM, Aymeric Vitte
<[email protected] <mailto:[email protected]>> wrote:
stop/resume:
Indeed as I mentioned this is related to WebCrypto Issue22
but I don't think this is a unique case. Issue22 was closed
because of lack of proposals to solve it, apparently I was
the only one to care about it (but I saw recently some other
messages that seem to be related), and finally this would
involve a public clone method with associated security concerns.
But with Streams it could be different, the application will
internally clone the state of the operation probably
eliminating the security issues, as simple as that.
To describe simply the use case, let's take a progressive
hash computing 4 bytes by 4 bytes:
incoming stream: ABCDE bytes
hash operation: process ABCD, keep E for the next computation
incoming stream: FGHI bytes + STOP-EOF
hash operation: process EFGH, process STOP-EOF: clone the
state of the hash, close the operation: digest hash with I
So, here, partial hash for ABCDEFGH is output
No, you get the digest for ABCDEFGHI and you get a cloned
operation which will restart from ABCDEFGH
OK.
resume:
incoming stream: JKLF
hash operation (clone): process IJKL, keep F for next
computation
etc...
and if we close the stream here we'll get a hash for
ABCDEFGHIJKLFPPP (P is padding). Right?
If you close the stream here you get the digest for ABCDEFGHIJKLF
resume happens implicitly when new data comes in without explicit
method call say resume()?
Good question, I would say yes, so we don't need resume finally, but
maybe others have different opinion, let's ask whatwg if they foresee
this case.
So you do not restart the operation as if it was the first
time it was receiving data, you just continue it from the
state it was when stop was received.
That's not so unusual to do this, it has been requested many
times in node.
--
Peersm :http://www.peersm.com
node-Tor :https://www.github.com/Ayms/node-Tor
GitHub :https://www.github.com/Ayms
--
Peersm :http://www.peersm.com
node-Tor :https://www.github.com/Ayms/node-Tor
GitHub :https://www.github.com/Ayms
--
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
