• Minumum TLSv1.2
• Cipher suite default: ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256
• Switch to server preference for cipher choice

ssllabs.com https://www.ssllabs.com/ssltest/analyze.html?d=yay.im

This is rejecting a number of (admittedly very old) clients so we might want to loosen the defaults a bit?

We add strict validation for the headers that are present in the header name and the header field. We have a special case for pseudo headers, since there's a limited list of those that are allowed.

Hello

Here's a first proof-of-concept regarding an ad-hoc tracer for h2o based off dtrace probes. The aim was to be cost free when not attached, and still performant under load.

I implemented a small test client for it in python using EBPF/BCC, but any language can be used really. The script is here, and would require BCC. I pasted a sample output below.

The PR implements a communication socket to the tracing program. It allows to stop any tracing processing if the tracer program disconnects or crashes, and also some lightweight communication to filter out some events from being processed. This socket port is settable using the config below.

Cheers !

listen:
    port: 4321
    tracing: ON

% sudo ./picotracer.py `pgrep h2o`
>> 1553636178731756      36    SSLNew            TLSv1.3 AES256-GCM 0x7ff626ffcac0
>> 1553636178731756      36    NewConnH2         10.0.2.15:9090 10.0.2.15:34200
>> 1553636178731756      36    RxHeader          user-agent curl/7.64.0
>> 1553636178731756      36    RxHeader          accept */*
>> 1553636178731756      36    NewReq            HTTP/2 GET /assets/2.ts
>> 1553636178731756      36    Proxy             [unix:/tmp/h2o.sock]
>> 1553636178731756      36    ProxyTxHdr        user-agent curl/7.64.0
>> 1553636178731756      36    ProxyTxHdr        accept */*
>> 1553636178731756      36    ProxyNewReq       HTTP/1.1 GET /assets/2.ts
>> 1553636178731756      36    ProxyRxHdr        date Tue, 26 Mar 2019 21:36:18 GMT
>> 1553636178731756      36    ProxyRxHdr        content-type video/mp2t
>> 1553636178731756      36    ProxyRxHdr        last-modified Mon, 06 Aug 2018 09:07:10 GMT
>> 1553636178731756      36    ProxyRxHdr        etag "5b680fbe-1a8780"
>> 1553636178731756      36    ProxyRxHdr        accept-ranges bytes
>> 1553636178731756      36    ProxyNewRes       HTTP/1.1 200 len: 1738624
>> 1553636178731756      36    TxHeader          date Tue, 26 Mar 2019 21:36:18 GMT
>> 1553636178731756      36    TxHeader          content-type video/mp2t
>> 1553636178731756      36    TxHeader          last-modified Mon, 06 Aug 2018 09:07:10 GMT
>> 1553636178731756      36    TxHeader          etag "5b680fbe-1a8780"
>> 1553636178731756      36    TxHeader          accept-ranges bytes
>> 1553636178731756      36    NewRes            HTTP/2 200 len: 1738624

When a transfer-encoding:chunked transfer is interrupted in the backend by a connection close, H2O currently just closes the frontend stream. This makes it not possible for the client to know that it's receiving truncated data, whereas it would be possible over plain HTTP/1.1, since the last chunk would be missing - Chrome and curl both report errors on truncated HTTP/1.1 chunked transfers, FF and Safari do not, as far as I can tell -. This adds a test that checks that a broken transfer-encoding:chunked transfer is translated into a RST_STREAM over H2.

Just a question: I sometimes get a lot of these in the kernel log messages on FreeBSD and HardenedBSD systesm running h2o.

pid 56341 (h2o), uid 80: exited on signal 6

Is this to be expected? Why does it exit so often?

Note, there is nothing to be found in the h2o error log and neither in the php-fpm.log.

I'm trying to wrap my head around these mruby handlers used by h2o. I'm on h2o 1.7.0 from FreeBSD ports. This is what I'm trying right now, found at https://github.com/h2o/h2o/pull/405#issuecomment-136281330

hosts:
  default:
    paths:
      "/":
        mruby.handler: |
          H2O.return 403, "Access Forbidden", "I will never show you this!"

When I try to start h2o, I get:

Starting h2o.
[/usr/local/etc/h2o/h2o.conf:58] unknown command: mruby.handler
/usr/local/etc/rc.d/h2o: WARNING: failed to start h2o

What am I doing wrong?

Tasks:

• [ ] bundle mruby-string-crypt
• [ ] adjust http://lowreal.net/2015/11/17/1 to read the password file, and bundle it

Format of htpasswd file is specified in https://httpd.apache.org/docs/2.2/misc/password_encryptions.html.

relates to #203

Any plans for supporting QUIC?

It seems that currently QUIC doesn't have a lot of changes over HTTP2(same HPACK, same semantics) layer, instead its main focus it's to improve upon TCP, by replacing it with UDP. I wonder if you've thought about it? I'm searching for a high performance QUIC/HTTP2 webserver.

I guess, ideally, it would be only a matter of swapping the TCP under the current HTTP implementation, with QUIC's UDP replacement. But I guess it isn't that easy? Isn't it?

How would you do it if you were to work on it?

Thanks.

Hello,

I am trying to stress test h2o using h2load. Whenever a large number of requests fails h2load doesn't report any error status codes. I suppose it is not getting the response code from h2o

 h2load -n200000 -c1 -m100 -i ~/h2o-1.5.0-beta2/SCRIPTS/all_urls.txt


starting benchmark...
spawning thread #0: 1 total client(s). 200000 total requests
TLS Protocol: TLSv1.2
Cipher: ECDHE-RSA-AES128-GCM-SHA256
Server Temp Key: ECDH P-256 256 bits
Application protocol: h2
progress: 10% done

finished in 4.65s, 5956.86 req/s, 30.54MB/s
requests: 200000 total, 27826 started, 200000 done, 27726 succeeded, 172274 failed, 172274 errored, 0 timeout
status codes: 27726 2xx, 0 3xx, 0 4xx, 0 5xx
traffic: 149060220 bytes total, 1443027 bytes headers (space savings 71.53%), 147058038 bytes data
                     min         max         mean         sd        +/- sd
time for request:     3.92ms    106.90ms     14.17ms     10.23ms    86.44%
time for connect:     5.10ms      5.10ms      5.10ms         0us   100.00%
time to 1st byte:    14.04ms     14.04ms     14.04ms         0us   100.00%
req/s           :    5958.32     5958.32     5958.32        0.00   100.00%

As You can see a lot many requests have failed but no error status code has been reported. Also, I'd like to ask is it fine that a bigger bunch of requests are getting failed?

This PR is for https://github.com/h2o/h2o/issues/1329

TODO:

• [x] add queue for when ch.push is called before ch.shift
• [x] add tests
• [x] use script to create embedded code

This PR adds an initial absolute priority header support based on draft-kazuho-httpbis-priority-04.

This PR is an initial prototype and has several assumptions:

• Back-end (e.g. file handler, reverse proxy origin) adds the priority header.
• Request priorities from a client are modified based on back-end priority headers.
• As for client-generated priorities, only assumes Chromium-style dependency tree (linear, weight-sorted list)
• Only urgency parameter is interpreted. incremental parameter is ignored at the moment.

A gcc builtin function __builtin_clzll is better to compute int(floor(log2(x))). I'll provide a patch for Visual Studio if you want to support the compiler.

A test code is here.

The libh2o-*.a libraries are not fully usable when Link Time Optimization (LTO) is enabled ; and some symbols are not present in the static libraries.

This PR is an attempt to merge #2976 into latest main.

#2976 consists of two major changes: 1) addition of an API to read from file asynchronously, 2) changing the "read" callback of h2o_sendvec_t to support asynchronous access.

At the moment when #2976 was written, h2o_sendvec_t were flattened inside the HTTP layer, but now, we have h2o_socket_sendvec that allows applications pass pullable vectors into the socket layer.

Therefore, this PR is an attempt to land 1 at the same time re-plumbing the asynchronous read callback of h2o_sendvec_t so that the files can be read asynchronously after h2o_socket_sendvec is called.

Hi all,

We are trying to stream DASH traffic over http3.

We used h2o as http3 server and on the client side dash.js player is being used for playback (in chrome browser version 108.0.5359.98).

However, we observed that the stream (video chunks) are being transmitted over HTTP/1.1 , although chrome supports HTTP/3.

Even when we are trying to simply load the home page of server (index.html) in Google chrome then that communication is also happening over HTTP/1.1. Using Firefox and cURL also we get the same results.

So, we tried using the experimental version of cURL (with http3 support). In this case, the communication happens over HTTP/3 only when we explicitly use the --http3 option with cURL. But cURL doesn't provides support for DASH playback.

The expected behaviour is that the server should use HTTP/3 if the client supports it, else it must fall back to HTTP/2 or lower version. I have been using the configuration file provided in examples/h2o/h2o.conf.

Do I need to make any specific changes to the h2o server configuration file to use HTTP/3 as the default protocol while serving client requests? Or some configuration is required on the client side?

Do we need to use a different DASH player that supports HTTP/3? If yes, then can you please suggest the name of any such player?

Thanks

Issues #2991. 'libuv' is used only by 'libh2o' and some examples. This PR removed 'libh2o' and some examples which depend on 'libuv'. The standalone server and library 'libh2o-evloop' doesn't depend on 'libuv'. Library users can use 'libh2o-evloop' instead 'libh2o'.