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.

> 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.

Sorry I was out and about and couldn’t reply earlier.

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