Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

This is not really an issue with HTTP/2 as framing specifies the end of
the stream explicitly. This would become a problem with HTTP/1, notably
with chunked encoding.

It was not possible to use it outside of functions.
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

Gathered data means b_vcl

The prototype of timegm() does not have 'const'.

This fixes compilation on OS/2 which have only a declaration of
timegm().
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

This is currently and transitionally used to test HTTP/2 over TLS.
Eventually, this should be done automatically.

Going forward, this will either be removed or used without TLS.

The major version must be one, and the error code must be successfully
extracted.

The version can only ever be 1 (meaning 1.1, the default) or 0
(meaning 1.0, the fallback).

This plugin does not support version 2.0 or obsolete version 0.9.

i_version is always (1.)1 here.

No functional changes

This adds a new plugin for HTTPS supporting HTTP version 2.0
(IETF RFC 7540), and based on the latest version of HTTP protocol
semantics (IETF RFC7230-9 series).

It provides support for seeking in a single round trip time by
reusing the same TCP connection and TLS session. It could be further
extended to reusing connections over multiple access instances,
e.g. to support segmented streaming.

It also addresses a number of protocol bugs in the existing HTTP
stack, such as handling of HTTP 100, 201 and 416 codes. It also adds
automatic safe reconnection.

Currently, the old HTTP access is favored due to a few missing
features:
- HTTP 1.1 fallback - work in progress,
- proxies (i.e. HTTP CONNECT) - work in progress,
- authentication,
- cookies.

This would keep track of HTTP(S) connections to enable reuse (HTTP 1)
or multiplexing (HTTP 2). Initially, the connection manager will be
scoped to the access module, so it only handles a single authority
and a single pending request.

This is the return value of a thread that has terminated due to
cancelation.

This demultiplexes incoming HTTP/2 frames and dispatches them to
HTTP/2 streams.

It seems impossible to handle interruptions while waiting on a
condition variable otherwise.

In particular, a single vlc_cond_wait_i11e() function would be
intrinsically prone to deadlocks:
 - It would need to acquire the interrupt context lock while the caller
   already holds the mutex corresponding to the condition variable, but
 - the interrupt callback would need to acquire the mutex while holding
   the interrupt context lock.
This would be a classic lock inversion race.

This addition should also enable hooking with other libraries, such as
Glib´s GCancellable.

Be very careful when using these two new functions. VLC does not
support stacking interrupt handlers (at least not currently). So there
MUST NOT be any call to another interruptible function between
vlc_interrupt_register() and vlc_interrupt_unregister().