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