Here is the config file:

num-threads: 2
listen: 8080
listen:
port: 8081
ssl:
certificate-file: examples/h2o/server.crt
key-file: examples/h2o/server.key

hosts:
"127.0.0.1.xip.io:8080":
paths:
/:
file.dir: examples/doc_root
access-log: /dev/null

"alternate.127.0.0.1.xip.io:8081":
listen:
port: 8081
#port: h2o_unix
#type: unix
ssl:
certificate-file: examples/h2o/alternate.crt
key-file: examples/h2o/alternate.key
paths:
/:
file.dir: examples/doc_root.alternate
access-log: /dev/null

from h2o.

Maybe the question that I made about how listener threads are managed have something with this?

mingodadDecember 23, 2014 at 2:46 PM
I was looking at the src/main.c and found that each thread is creating it's own listeners queue using the server listeners. Isn't this a mistake ?
What will happen when there is more than one thread ?
All of then will wakeup and try to manage the accepted socket ?
Why not accepting the listeners only in main process and distribute the accepted sockets to threads after ?

Am I missing something here ?

Cheers !

from h2o.

Thank you for reporting the issue. I have successfully reproduced the problem.

from h2o.

The problem is in Apache Bench.

The tool does not implement the HTTP specification correctly; it fails to detect the content-length header all in lowercase letters as H2O sends (see https://github.com/apache/httpd/blob/trunk/support/ab.c#L1581).

from h2o.

Changed H2O to send the essential headers with the first letters uppercased.

from h2o.