BiagioFesta / ls-qpack-rs

QPACK Field Compression for HTTP/3 RFC 9204 in Rust based on ls-qpack
Apache License 2.0
6 stars 5 forks source link

feat: add support for lsqpack_enc_decoder_in from Encoder #11

Closed Ousret closed 5 months ago

Ousret commented 5 months ago

Hello,

I am submitting this PR to add support for "lsqpack_enc_decoder_in" function. From ls-qpack upstream docs we can read about its purpose "Process next chunk of bytes from the decoder stream".

See https://github.com/litespeedtech/ls-qpack/blob/521792711f2839f05565fd3dd617708cfb5b80ee/lsqpack.h#L288

There's another thing I'd like to see, but I don't see how we can without breaking the compatibility. I am fairly new to Rust, so I am requesting your advises on this one:

In decoder.rs, looking at the lsqpack_dec_header_in function wrap/bridge, I can see that you don't want to retrieve the "control"/"stream" data by passing the two last argument to respectively NULL and 0. How can we still retrieve this? Because I need it. This part return (on the Ok path) a Vec of Header, while it should normally do the same as the encoder by returning a DecoderResult wrapping the stream/control data along with the Vec of Header, Am I wrong?

let result = unsafe {
    ls_qpack_sys::lsqpack_dec_header_in(
        &mut this.decoder,
        hblock_ctx.as_mut().as_mut_ptr() as *mut libc::c_void,
        stream_id.value(),
        header_block_len,
        &mut cursor_after,
        encoded_cursor_len,
        std::ptr::null_mut(),  // normally for dec/stream ctrl data, here ignored.
        &mut 0,
    )
};

Regards,