Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96255
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.67 as permitted sender)
To: PHP Internals <internals@lists.php.net>
References: <1de78ecd-74e5-438c-9744-103163218ebd@gmail.com>
 <CANUQDCheUqiYfnzW8D27MV8jK71eBUU7MsFn1Fb6A2Qv30tYLQ@mail.gmail.com>
Message-ID: <5991de8e-d962-dea9-b010-d53586827db7@gmail.com>
Date: Wed, 5 Oct 2016 19:20:34 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <CANUQDCheUqiYfnzW8D27MV8jK71eBUU7MsFn1Fb6A2Qv30tYLQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Add support for HTTP/1.1
From: rowan.collins@gmail.com (Rowan Collins)

Hi all,

It sounds like the feeling so far is quite positive. I'll have another 
look for a dupe, then file a bug for the missing 100-continue support, 
and try to work on a patch. Once that's in place, and unless anyone 
comes up with other major features we need to support, we can discuss 
whether we should make it the default, or at least easier to opt into.


On 03/10/2016 09:43, Niklas Keller wrote ...:
> I think we already send it starting with 7.0, maybe just for 1.0, 
> because there are some servers that respond correctly with an HTTP/1.1 
> response to an HTTP/1.0 request, but fail to close the connection and 
> imply "Connection: close" for those requests.

... and on 05/10/2016 17:14, Andrea Faulds wrote:
> In order to connect to many modern websites, you need a Host: header, 
> and in order to use a Host: header, you need to use HTTP/1.1 (if you 
> don't, servers will sometimes send you back a 1.1 response anyway!).

Indeed, checking 7.0 suggests that we are unconditionally sending both a 
Host: header and Connection: Close with every request, while still 
claiming "HTTP/1.0". I believe both headers are technically backwards 
compatible with servers (i.e. ignored by) that genuinely speak HTTP/1.0, 
so this is not technically "wrong". However, the fact that it's 
necessary does strengthen the case for implementing HTTP/1.1 in full, 
rather than backporting features bit by bit.



On 04/10/2016 09:55, Björn Larsson wrote:
> Would fixing
> this behaviour also be applicable for HTTPS? 

Yes, I'd be very surprised if this code wasn't shared between the two 
contexts. (It's a little more complicated than just piping an "http" 
connection through a "tls" one, because of things like SNI, but there'd 
be no reason to have the actual header processing code twice.)

Regards,

-- 
Rowan Collins
[IMSoP]