On Mon, Feb 3, 2014 at 5:32 AM, Fabian Frank <fabian.frank.de_at_gmail.com>wrote:

> On Jan 31, 2014, at 8:15 AM, Tatsuhiro Tsujikawa <tatsuhiro.t_at_gmail.com>
> wrote:
>
> > Good progress. client header and SETTINGS submissions look good.
> Thanks, I'm glad the approaches are similar and since they are there
> shouldn't be an issue if we move ahead with either patch set. :-)
>
> > The idea is mostly the same, I add some extra code such as converting
> HTTP header from curl to HTTP2 format and calls underlying recv/send
> callback including TLS and non-TLS.
> I see that you chose to parse the HTTP 1.1 data as opposed to using the
> data that is already on the connectdata struct, see my patch for how I try
> to take the data out of the struct. I thought it would be more stable to
> use the data from the struct, as opposed to parsing the data. I'm a bit
> worried that we'll in fact implement an HTTP1.1 to 2.0 proxy inside curl if
> we go down the road of getting the info out of the HTTP1 stream, as opposed
> to implementing 2.0 directly. IMHO the latter would be more stable and more
> efficient. What do you think? I'd like to understand why you chose this
> approach / consider it more suitable. If we are concerned about reusing the
> existing http logic, maybe we could break http.c into http.c and an http1.c
> so that we can reuse the HTTP logic and keep the transport specifics into
> http1.c and http2.c? I just thought I'd bring this up while we are in the
> early stage and the code can be adjusted easily.
>
>
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. While it is true that all relevant
information is in the struct, building HTTP request requires many
conditionals as you see in http.c. My patch is intended as an experiment of
a first step of integrating HTTP2 into curl and asses what is needed and
what is missing in curl, so I'd like to keep the patch small and
un-obtrusive. That's why I chose that path. For long term solution, I'm
sure think there are better approach.
I think we are sure to reuse parts of existing HTTP/1 implementation
because HTTP2 doesn't change HTTP/1 semantics and curl is doing good job
for implementing HTTP/1. Splitting current http.c into http1.c and http.c
is a possible way to go. 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.

> > Anyway, with this patch, one can transfer contents from
> https://twitter.com
> It seems that twitter.com does not completely work yet, a gzip encoded
> response is not decompressed right now. I don't think it's a big deal /
> hard to fix though, just wanted to mention it as I noticed that when
> playing with your changes.
>
>
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.

Best regards,
Tatsuhiro Tsujikawa

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-02-03