On Mon, 3 Feb 2014, Tatsuhiro Tsujikawa wrote:
Parsing HTTP/1 request header is definitely a hack for as a first shot implementation. I agree that it is better to use data in existing struct because we can save the parser overhead.
Right, an alternative would be to do the request in an internal format and then have two different functions convert them to the protocol on the wire with less overhead and better performance. Otherwise I agree with you Tatsuhiro that by converting the HTTP1 header we do get to leverage the existing HTTP requet logic without a lot of work. It'll also automatically work with features that for example add or remove headers and more.
In the near future, we need to share HTTP2 connection with multiple HTTP request. This separation of layers would be a good layer abstraction for curl.
We will then make sure that the pipelining logic can be applied to and used with http2 as well. It detects existing connections to the same host so that multiple easy handles can use the same. It'll be a much better pipelining though since it can be used with much less restrictions compared to HTTP1.
Curl needs --compressed. The thing is that in HTTP2 server can send gzipped response without seeing accept-encoding: gzip, deflate in HTTP request. Twitter utilizes this fact.
But we know it is compressed thanks to some header in the response, right? We should then fix the code so that http2 + header does the auto-decompress logic automatically. Right?
-- / daniel.haxx.se ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
