Re: [quicwg/base-drafts] Possible HoL blocking due to co-mingling payload and metadata (header) address space. (#1606)

[Martin Thomson <[e-mail]>]

I'm inclined to suggest that this is something that could be addressed in an extension.  Imagine that both peers negotiate a new interaction mode whereby request and response bodies are carried on other streams.  (For @LPardue: that new stream couldn't use DATA frames though, or you lose random access, not knowing where the frame headers are inserted.)  Establishing which stream maps to which request is tricky, but probably able to be resolved in a way that meets the requirements.  I suspect that you can't avoid having at least *some* metadata, but it might be possible to use a signaling mechanism for that that can be isolated from the worst of the HOLB.

The OP suggests that metadata might not be important, which suggests that maybe this isn't as much HTTP as is claimed.  In some ways, the more useful this protocol is for this sort of use case, the less it resembles HTTP.  We should explore that some more.

I realize that there are benefits to this being the standardized approach for HTTP, but we'd need to resolve the question of similarity first.  After that, we need to recognize that the structure of the current design is intentional and addresses real issues (though for some, that depends on how much you believe server push to be relevant).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1606#issuecomment-407951291