Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:82282 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 48950 invoked from network); 9 Feb 2015 13:52:24 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Feb 2015 13:52:24 -0000 Authentication-Results: pb1.pair.com header.from=mike.php.net@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=mike.php.net@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.181 as permitted sender) X-PHP-List-Original-Sender: mike.php.net@gmail.com X-Host-Fingerprint: 74.125.82.181 mail-we0-f181.google.com Received: from [74.125.82.181] ([74.125.82.181:35121] helo=mail-we0-f181.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 21/53-50460-89BB8D45 for ; Mon, 09 Feb 2015 08:52:24 -0500 Received: by mail-we0-f181.google.com with SMTP id w62so9589767wes.12 for ; Mon, 09 Feb 2015 05:52:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=p2e9KX85z5y1pN0v1DK/54na/I/2cYSMqNIloBQLCWs=; b=iEYRy+7VKVczWODPRZWvmFo6E60eos8rcQEAtOkvuMddmkV/Ec2Zi3fi/GzrZP4DRp mCjBYlij+jElpmVgISV4fhNbO5PNsX6LxDIj+/v/WN/I6bjoJB6btNoWuG4sa396LBEF BLXLisVO39jKaEMIYhB51V8/1b3MhuepQV20YeM0rxSw/6q1ptscQwC2POKtHiVXQCo7 qqYSsWVc0DKZmz+q9gC0ZtaS6mLlxuDiVJo8zYTmMgpeOAj05VRIz5ICVUVPJHO/Y78T uncx+7lp2iRn2PCN77Z0rAyokKWpyrr6aHFiJSTYtVFwLjISuxhVOS4EyKEamjv6Jn2+ dyvQ== X-Received: by 10.180.205.210 with SMTP id li18mr35855687wic.39.1423489941557; Mon, 09 Feb 2015 05:52:21 -0800 (PST) Received: from [192.168.2.120] (89-104-28-113.customer.bnet.at. [89.104.28.113]) by mx.google.com with ESMTPSA id bv16sm14547429wib.0.2015.02.09.05.52.20 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Feb 2015 05:52:20 -0800 (PST) Sender: Michael Wallner Message-ID: <54D8BB94.80301@php.net> Date: Mon, 09 Feb 2015 14:52:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Stanislav Malyshev , Pierre Joye CC: PHP internals References: <54D217E7.8030407@php.net> <54D2AE91.8090800@gmail.com> <54D3271E.2080207@php.net> <54D3CE01.4070903@php.net> <54D3D26A.6050405@gmail.com> <54D3D51C.8070108@php.net> <54D3D6A4.3020908@gmail.com> <54D47379.8030409@php.net> <54D7E259.4090702@gmail.com> In-Reply-To: <54D7E259.4090702@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http From: mike@php.net (Michael Wallner) On 08/02/15 23:25, Stanislav Malyshev wrote: >> Youself said that HTTP is a stateless protocol, so how would a >> connection in an "unclean state" look like in your opinion? > > Connection and protocol are different things. In connection, you could > be in the middle of the protocol - i.e. sending headers, sending body, > receiving headers, receiving body - and these are different states. > >> Curl caches connections the servers are fine with keeping alive, and I >> cache curl handles grouped by the id you pass to the client constructor >> and the authority of the url, that's all, nothing spooky. > > Caching connections within the same request and reusing them is not > spooky, but caching them long term, across requests, across security > domains, for extended time - is spooky. > Everything you said also applies to database connections; there are even database services that work over HTTP. I'm still having a fairly hard time groking the issue at hand, sorry. -- Regards, Mike