Download
Browse source Changelog
Documentation
Project   Known bugs   TODO Protocols   CA bundle   HTTP Cookies   HTTP/2   SSL Certs Releases   Security   Version numbers   Vulnerabilities curl tool   man page   Tutorial   HTTP scripting Who and Why
libcurl
ABI API Competitors Examples Features Mailing list Related libs Using libcurl Tutorial Testimonials
Get Help
curl-library curl-users curl-announce curl-commits Book: Everything curl Report a bug Mail Etiquette
Development
Autobuilds Code Style Contribute Internals Release Notes Release Procedure Roadmap Run Tests Security Specifications Test curl
News
Changelog Release table
curl / Mailing Lists / curl-library / Single Mail

curl-library

RE: [some ideas on] QUIC in curl

From: Lucas Pardue via curl-library <curl-library_at_cool.haxx.se>
Date: Wed, 28 Jun 2017 14:23:19 +0000

> Hey friends,
>
> I'm sure some of you have heard about QUIC and the standardization of this
> protocol that is done within the IETF. The IETF version of the protocol differs
> significantly from Google's version of the protocol, the version they've
> deployed in their browser and servers for a few years now.
>
> The IETF process has recently issued a "first implementation draft" and a few
> open source libraries have popped up that look like contenders for curl to
> use in order to start supporting QUIC.
>
> This is still early days of the protocol, but I decided to jot down some
> thoughts of mine on what it will take for us to support QUIC in curl:
>
> https://github.com/curl/curl/wiki/QUIC
>

Thanks for writing these up. Two areas I have some ideas on:

1) HTTP mapping
As you're probably fully aware, QUIC doesn't just carry HTTP/2 frames - it subsumes things and generally messes around. (lib)curl shouldn't expect to just be able to reuse libnghttp2 (in its current form). Therefore the selection of QUIC library should probably be cognisant of what will provide the HTTP/QUIC implementation, and how well those components would integrate. Substitution of components (i.e. do you want to support plugging of different HTTP/QUIC implementations, or pick one) should probably be discussed or at least written down.

2) Alt-Svc
While Alt-Svc is needed for QUIC, QUIC isn't needed for Alt-Svc. What I mean is do you see a piece of work on Alt-Svc covering all aspects of its capabilities, or to constrain it to QUIC? ALTSVC frame handling springs to mind.

How closely coupled with libcurl do you see your Alt-Svc cache being (could it be a completely separate component?). I think an in-built Alt-Svc cache for the curl tool makes a lot of sense, however for libcurl I'm not so sure. Without putting too much thought into it, what would be really nice is a libcurl interface that allows me to supply alternatives to a host (perhaps as part of a curl easy/multi handler) - then I can chose to manage the Alt-Svc's using the "Stenberg cache", or one provided by my system, or one I wrote myself.

Regards
Lucas

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2017-06-28