Connection header in response is always set to 'close' by response handler

[khageshsaini]

• Laravel Version: 5.4
• PHP Version: 5.6.23
• Database Driver & Version:

Description:

The response header 'Connection' is always set to 'close' by response handler. If the header set function is called to manually assign 'Connection' header to 'keep-alive', then response contains comma separated string 'keep-alive, close' which browser/client interprets as 'close'. This is present from v5.2.

Steps To Reproduce:

use response()->json($array, 200, ['Connection' => 'keep-alive']) to set the keep-alive header. The incorrect header for 'Connection' will be passed in response.

[DuckThom]

Cannot seem to reproduce this in tinker nor artisan serve in L5.2, L5.3 and L5.4 on PHP 7.

Laravel 5.2 tinker (same headers with curl -I):

>>> (string) response()->json([], 200, ['Connection' => 'keep-alive'])
=> """
   HTTP/1.0 200 OK\x0D
   Cache-Control: no-cache\x0D
   Connection:    keep-alive\x0D
   Content-Type:  application/json\x0D
   \x0D
   []
   """

Laravel 5.3 tinker (same headers with curl -I):

>>> (string) response()->json([], 200, ['Connection' => 'keep-alive'])
=> """
   HTTP/1.0 200 OK\x0D
   Cache-Control: no-cache\x0D
   Connection:    keep-alive\x0D
   Content-Type:  application/json\x0D
   \x0D
   []
   """

Laravel 5.4 tinker (same headers with curl -I):

>>> (string) response()->json([], 200, ['Connection' => 'keep-alive'])
=> """
   HTTP/1.0 200 OK\r\n
   Cache-Control: no-cache, private\r\n
   Connection:    keep-alive\r\n
   Content-Type:  application/json\r\n
   Date:          Tue, 30 May 2017 21:43:29 GMT\r\n
   \r\n
   []
   """

My guess is that your web server is adding that header value somewhere.

[shawjak3]

I am seeing the exact same issue on 5.4.22 and 5.4.23. I am doing a post request using Vue js and axios (both included libraries in the project) and its always set to close for me also.

[terax6669]

Happens only on Apache (tested 2.4.10, 2.4.18 and 2.4.29), Nginx is working fine. Reproduced this on Debian 8, Ubuntu (16, 18) using Laravel 5.6.38 and only when some unknown conditions are met. I wasn't able to pinpoint them, but it's not related to any request headers/methods. Apache downgrades response from HTTP1.1 to HTTP1.0. I was able to reproduce this consistently using any route in Dingo API, while all routes on Voyager were working fine, so with the context from OP it looks like it might be happening when using JSON responses (however simply returning an array from a web controller works just fine).

While this might be some weird Apache bug/feature, I'd be nice to pinpoint the issue. Maybe it's something that can be fixed in our apps.

curl output:

*   Trying [IP]...
* TCP_NODELAY set
* Connected to [DOMAIN] ([IP]) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: CN=[DOMAIN]
*  start date: Aug 30 07:19:15 2018 GMT
*  expire date: Nov 28 07:19:15 2018 GMT
*  subjectAltName: host "[DOMAIN]" matched cert's "[DOMAIN]"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
> POST [PATH] HTTP/1.1
> Host: [DOMAIN]
> User-Agent: curl/7.54.0
> accept: application/json
> Content-Type: application/json
> Content-Length: 61
>
* upload completely sent off: 61 out of 61 bytes
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Date: Thu, 13 Sep 2018 11:56:16 GMT
< Server: Apache/2.4.10 (Debian)
< Cache-Control: private, must-revalidate
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
< Access-Control-Max-Age: 1000
< ETag: "b80ea2b68fe8040c9f1543d8e6081a63bb237041"
< Content-Length: 12
< Connection: close
< Content-Type: application/json
<
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, Client hello (1)

[driesvints]

Closing this issue because it's already solved, old or not relevant anymore. Feel free to reply if you're still experiencing this issue.

[terax6669]

?
I just said it happened on 5.6.38... Want me to try and reproduce this on 5.7 or what?

[driesvints]

@terax6669 you're indicating that this is an Apache issue. Perhaps it's best to first figure out what's actually causing this before we're sure that it's a bug with the framework.