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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
