Swoole-src: Sending multiple headers at once with benchmarking tools

[vasily-kartashov]

When using ab or wrk with swoole, I noticed that the tests fail once you try to send multiple headers at once.

This works:

$response->header('Content-Type', 'application/json');
$response->end(json_encode('hello'));

but this doesn't:

$response->header('Content-Type', 'application/json');
$response->header('Content-Lenght', 7);
$response->end(json_encode('hello'));

Leading wrk to state that

Accessing URL http://tfb-server:8080/json: 
Verifying test json for swoole caused an exception: HTTPConnectionPool(host='tfb-server', port=8080): Read timed out.

[vasily-kartashov]

In fact this seems to be something very specific about Content-Length header. If I change the header to X-Content-Length everything seems to be working fine.

[twose]

Fixed via #2062, Content-Length will be ignored.
Don't send it by yourself, it's not necessary at all, the multi same header lead to protocol error.

[vasily-kartashov]

Can you point me to the complete list of headers that are sent automatically by swoole so that I can filter them out? Thanks.

[ghost]

I think it's a wide topic and depending on your _kind of response_. I guess, those, which are _needed as minimum to fullfill the request_ (response) will be sent.

As far as i can remember, if you simply $response->end(), the minimum alongside a status of 200 is:

Connection: keep-alive
Content-Type: text/html
Content-Length: =>0
Content-Encoding: gzip
Date: GMT
Server: swoole-http-server.

Those like status, type mostly should be and those like server can be overwritten, connection can be closed, encoding is variable and has changed in swoole > 4.1.0 to a better automatism of _compression type_

But you can check this simply by testing all needed kinds of response

[twose]

flddr find a good way.
Swoole will filter the content-length header (but we forgot to do it on the server side), because you may not always calculate the correct length, but Swoole will help you complete.

[vasily-kartashov]

because you may not always calculate the correct length

this is not a very good argument, frankly. For example, I might accidentally shoot myself in the head, while compiling swoole, but this is not necessarily something that swoole must address.

It's kind of OK to have headers "overlay", although I'd personally prefer them to be optional and managed by a server setting, e.g. override_headers => 1.

But you can check this simply by testing all needed kinds of response

Thanks, although it took me 2 days to pin down the single Content-Length issue. I think a simple pointer to the source code where it happens will be significantly more efficient than black-boxing the headers processing logic.

[twose]

@vasily-kartashov source in https://github.com/swoole/swoole-src/blob/master/swoole_http_server.c#L1718
except for content-length, other headers allows to be rewritten.

[ghost]

@vasily-kartashov

I think a simple pointer to the source code where it happens will be significantly more efficient than black-boxing the headers processing logic.

There is no _black-boxing_ 😉

[vasily-kartashov]

@twose, thanks for the pointer!