Summary: 32 instances, 30 unique

Text	Count
// TODO: Consider handling continuation frames without preceding	1
// TODO: The [error] can contain sensitive information we now expose via	1
// TODO: Consider splitting this method into client/server handling.	1
// TODO: Do not fragment if the number of bytes we can send is too low	1
// TODO: Support huffman encoding.	1
// TODO: We have to make sure that we	1
// TODO: Propagate this signal to the HPackContext.	1
// TODO: Do not fragment if the number of bytes we can send is too low	1
// TODO: Would we ever want to decrease the window size in this	1
// TODO: Handle stream/connection queue errors & forward to connection object.	1
// TODO: This can be optimized by delaying the window update to	1
// TODO: Once we start encoding via dynamic table we need to let the other	1
// TODO: When implementing priorities for HTTP/2 streams, these frames	1
// TODO: Do we need to do a runtime check here and	2
// TODO: There is probably more we need to wait for.	1
// TODO: We should wait for us to send the headers frame before doing this	1
// TODO: We may want to propagate cancel events as errors.	1
// TODO: No support for writing padded information.	1
// TODO: Currently we encode all headers:	1
// TODO: Take priorities into account.	1
// TODO: Have a timeout: When ACK doesn't get back in a reasonable time	1
// TODO/FIXME: If we pause and don't want to get more data, we have to	1
// TODO: When do we complete here?	1
// TODO: If all the frame writer methods would return the	1
// TODO: Somehow emit an error if too many continuation frames have been sent	1
// TODO: We currently write unconditionally to the [FrameWriter]: we might want	1
// TODO: Properly fragment large data frames, so they are not taking up too much	1
// TODO: No support for stream priorities.	1
// TODO: Make [StreamsHandler] call [connectionOut.startClosing()] once	2
// TODO: Can this even happen and if so, how should we propagate this	1