HTTP/1 pipelining vs new connections

ietf-tapswg / api-drafts

Architecture, interface, and implementation drafts for the definition of an abstract API for IETF TAPS

Other

23 stars 15 forks source link

HTTP/1 pipelining vs new connections #620

Open martinduke opened 4 years ago

martinduke commented 4 years ago

I found myself continually asking how I would implement foo-over-http/x using this API, and stumbled over ambiguity regarding HTTP 1.1 pipelining. While it's certainly possible to order messages in the proper way using this API, if I was writing this agnostically to HTTP version, it appears it would gravitate to opening a pooled TCP connection for each request/response if we ended up on HTTP/1 [because each request/response would have a clone() call]. Maybe this is OK, but I found this conclusion to be jarring.

mwelzl commented 4 years ago

I guess the question is: why would it make sense to use this API agnostically to the HTTP version? It seems weird to me that someone would want to use a new stream (or something of that nature - a new "Connection", somehow grouped if possible - which is what the API offers) when implementing HTTP/1.1?

CORRECTION: my answer here was based on thinking "implement HTTP over TAPS", not "implement foo over HTTP over TAPS". Whoever implements HTTP itself over TAPS should know what they're doing.

philsbln commented 3 years ago

Yes, there is an issue… we took quite some time to discuss this and I put a lot of effort in solving this with pooled connections, but it dropped out of the main API as we did not find an consensus how to tackle it.

I guess writing an HTTP mapping document that extend taps in a way that brings HTTP with pipelining, racing, multi-streaming and multi-path under one message abstraction would be the right way forward. I am happy to help with that one.