Implement QUIC-HTTP framing about quinn

[djc]

I don't think the frames match the HTTP spec itself, so I don't think you'll find much to use from the http crate.

I forgot to mention it, but I agree that a separate crate would make sense. To disambiguate the HTTP protocol version, I think it would be good to call it quinn-h3.

[passchaos]

Any progress?

[djc]

Not yet, we've been focusing on updating our spec compliance to the latest draft. Would you like to help out? I'm happy to mentor!

[passchaos]

Sorry, I am busy recently. I am happy to do this in the future.

[djc]

No problem, I figured it was worth asking. We'll get to it eventually, hopefully somewhat soon.

[stammw]

Hey! I'd like to start working on this next !

[djc]

@stammw great! The idea here is just to implement the bytes-to-types and types-to-bytes code for the data structures defined in the HTTP spec. Ideally the module would include unit tests that just check whether round-tripping works as expected. I think it would make sense to use the Codec trait as is used for example in the frame module (which should provide good examples).

Let us know if you have questions!

[Ralith]

It might be worth leveraging types from the http crate, though I'm not sure how much work might be required on their end to play well with HTTP3 concepts.

I'd also ideally like to see this be a separate crate in the workspace (e.g. quinn-http) so non-http users don't need to deal with the extra code/dependencies.

[stammw]

Hey,
What do you think about how I should handle the QPACK encoded frames (HEADERS, including PUSH_PROMISE ones) ?

1. Return HttpFrame variant that contains raw Bytes
2. Return HttpFrame variant that contains a stubbed QPACK type
3. Do not implement them for the moment

[Ralith]

In the interest of being able to run tests, stubbing them out seems most practical. Unless there's some conceivable use for the raw data other than immediately decompressing it?

[stammw]

Actually, I think QPACK wouldn't be a data type but a trait. So stubbing and using raw types inside variants might be more or less the same solution. And at the and the encode -> decode -> compare tests still be writable even if the given part would have to be changed afterward?

I wonder how much effort it would take to finish the existing QPACK PR... I worry that #130 will be blocked until then, eventually.

[stammw]

closed via #130