Compiling relayd with -DDEBUG=3 and watching the output gave me nothing. No errors what so ever about out of buffers or something else.
However, removing 'socket buffer 65536’ solved my problem. Br > 8 maj 2017 kl. 13:27 skrev Maxim Bourmistrov <m...@alumni.chalmers.se>: > > Hey, > I investigate a problem were TLS-asselerated machine response is incomplete. > I was able to reproduce this on OpenBSD 5.9, 6.0 and 6.1. Test on 5.8 is > about to be. > > Following env I have: > > relay1: relayd machine > web1: apache 2.2.31 serving the request > client1: requester > > relay1 is configured following way (relevant lines): > > http protocol http_relay { > tcp { nodelay, sack, socket buffer 65536, backlog 1024 } > match header append "X-Forwarded-For" value "$REMOTE_ADDR" > match header set "X-Forwarded-By" value "$SERVER_ADDR:$SERVER_PORT" > match header set "Keep-Alive" value "$TIMEOUT" > match request header remove "Proxy" > } > > http protocol tls_accel { > tcp { nodelay, sack, socket buffer 65536, backlog 1024 } > match header append "X-Forwarded-For" value "$REMOTE_ADDR" > match header set "X-Forwarded-By" value "$SERVER_ADDR:$SERVER_PORT" > match header set "X-Forwarded-Proto" value "https" > match header set "X-Forwarded-Port" value "443" > match header set "Keep-Alive" value "$TIMEOUT" > match request header remove "Proxy" > > tls { tlsv1, \ > ciphers "AES:!AES256:!aNULL" \ > } > } > > table <webpool> { 172.16.1.111 } > > relay int_test_tls { > listen on 172.16.1.99 port 443 tls > protocol tls_accel > forward to <webpool> port 80 mode roundrobin check http "/" code 200 > } > > relay int_test_http { > listen on 172.16.1.99 port 80 > protocol http_relay > forward to <webpool> port 80 mode roundrobin check http "/" code 200 > } > > web1 is a std Apache 2.2.31 with enabled deflate for the following > > AddOutputFilterByType DEFLATE application/json > AddOutputFilterByType DEFLATE text/html > AddOutputFilterByType DEFLATE text/plain > AddOutputFilterByType DEFLATE text/xml > AddOutputFilterByType DEFLATE text/css > AddOutputFilterByType DEFLATE application/x-javascript > AddOutputFilterByType DEFLATE application/javascript > > and serving a JS file. > > client1 is running PHP code from CLI to reproduce this problem. > > > Following is observed: > > 1. Client1 requests web1 directly on port 80 and gets full response > > shell$ php client3.php > Expected length: 547204 > Received length: 547204 > > [Response Headers] > HTTP/1.1 200 OK > Date: Mon, 08 May 2017 11:08:27 GMT > Server: Apache/2.2.31 (Unix) mod_ssl/2.2.31 OpenSSL/1.0.1e-fips > Last-Modified: Mon, 08 May 2017 07:22:43 GMT > ETag: "60319-85984-54efe1ae42be3" > Accept-Ranges: bytes > Content-Length: 547204 > Vary: Accept-Encoding > Connection: close > Content-Type: application/javascript > > 2. Client1 requests web1 directly on port 80 WITH GZIP enabled and gets full > response back > I see gzipped stream on the screen and then it gets decoded to a complete > file. File I get is not cut. > > Expected length: Content-Length not recieved > Received length: 165454 > > [Response Headers] > HTTP/1.1 200 OK > Date: Mon, 08 May 2017 11:10:18 GMT > Server: Apache/2.2.31 (Unix) mod_ssl/2.2.31 OpenSSL/1.0.1e-fips > Last-Modified: Mon, 08 May 2017 07:22:43 GMT > ETag: "60319-85984-54efe1ae42be3" > Accept-Ranges: bytes > Vary: Accept-Encoding > Content-Encoding: gzip > Connection: close > Content-Type: application/javascript > > 3. and 4. Clien1 requests relay1 on port 80 (with and without GZIP) and gets > complete response > > 5. Client1 requests relay1 on port 443 without GZIP - response is incomplete > > Expected length: 547204 > Received length: 396424 > > [Response Headers] > HTTP/1.1 200 OK > Accept-Ranges: bytes > Connection: close > Content-Length: 547204 > Content-Type: application/javascript > Date: Mon, 08 May 2017 11:14:59 GMT > ETag: "60319-85984-54efe1ae42be3" > Last-Modified: Mon, 08 May 2017 07:22:43 GMT > Server: Apache/2.2.31 (Unix) mod_ssl/2.2.31 OpenSSL/1.0.1e-fips > Vary: Accept-Encoding > > 6. Client1 requests relay1 on port 443 with GZIP - response is complete. > > > So non-gzipped response from behind the relay1 is incomplete while doing TLS > termination. > Files server.js and client.php can be provided upon request. > > Any ideas? > > Br > > >