preferable to be able to
initialize the curl share handle once with the share options. I've
fixed that issue in https://github.com/curl/curl/pull/14696, but of
course that won't be available for most people for quite some time.
Thanks!
Eric Norris
Apologies for any noise, but I'd like to bump this thread to poll for
input on whether people feel this pull request requires an RFC, and if
so, request RFC karma so that I may submit an RFC. I've already got
one vote from @SakiTakamachi for requiring an RFC.
I had an interesting discussion with @
ysqlnd driver's check_liveness function.
Thanks!
Eric Norris
15, 2020 at 10:38 AM twosee wrote:
>
> > 2020年8月15日 上午2:16，Eric Norris 写道：
> >
> > Hey internals,
> >
> > I've submitted https://github.com/php/php-src/pull/5935 as a way to
> expose
> > an underlying PDO driver's check_liveness function to user
Hello all,
After receiving some feedback about
https://github.com/php/php-src/pull/15603, I'm formally proposing an
RFC to add persistent curl share handles here:
https://wiki.php.net/rfc/curl_share_persistence
Thanks to those who have provided feedback so far! Of note: the
implementation introdu
Hello internals,
I have opened the vote for "Add persistent curl share handles":
https://wiki.php.net/rfc/curl_share_persistence
The vote will last for two weeks, until 2024-11-08 0:00 UTC.
Thanks!
On Mon, Nov 4, 2024 at 2:13 PM Jakub Zelenka wrote:
>
> On Mon, Nov 4, 2024 at 2:21 PM Jakub Zelenka wrote:
>>
>> Hi,
>>
>> On Wed, Oct 9, 2024 at 10:18 PM Eric Norris wrote:
>>>
>>> Hello all,
>>>
>>> After receiving some
> > Here's a pull request indicating that the curl team considers TLS
> > reuse safe: https://github.com/curl/curl/pull/1917. I believe they
> > consider it a vulnerability if you are able to make curl incorrectly
> > reuse a TLS session with differing TLS settings.
>
> Thank you. That would be use
> > That said, as I mentioned above I would be fine with removing cookie
> > jar persistence if that was necessary to secure a passing vote, since
> > it's not our primary focus.
>
> Given the information regarding the TLS re-use, the cookie sharing is my
> only remaining concern. In fact with cook
On Fri, Nov 1, 2024 at 2:59 PM Gina P. Banyard wrote:
>
> On Wednesday, 9 October 2024 at 21:16, Eric Norris
> wrote:
>
> > Hello all,
> >
> > After receiving some feedback about
> > https://github.com/php/php-src/pull/15603, I'm formally proposin
> On Fri, Oct 25, 2024 at 3:34 AM Tim Düsterhus wrote:
> Apologies, I wanted to chime in before the vote started, but I was too
> busy.
I appreciate that you took the time to respond at all, so thank you.
> Persistent handles / resources / objects violate PHP’s shared-nothing
> request model, wh
> >> Accidentally sharing a cookie jar for unrelated requests due to a
> >> badly
> >> chosen `$persistent_id` sounds like a vulnerability to is bound to
> >> happen to someone.
> >
> > I'll admit that I don't have a good response to this, since while I
> > agree this is possible, I don't think it
Hello again,
It has been two weeks, and unless there are any further comments I
plan on converting the above question into a voteable sub-question and
opening the RFC for votes tomorrow, Thursday October 24th.
Thanks!
Apologies Rob, I don't seem to be receiving individual emails from the
mailing list, so I'll have to respond to my own email here. I've
changed my subscription to receive all emails so hopefully I'll be
able to respond directly to future emails.
> It might be a good idea to get a “strong opinion”
Hello again internals,
Similar to the Random Extension improvement RFC
(https://wiki.php.net/rfc/random_extension_improvement), I am creating
an RFC to address possible improvements to the recently accepted curl
share persistence RFC
(https://wiki.php.net/rfc/curl_share_persistence).
https://wiki
On Thu, Oct 24, 2024 at 2:20 PM Eric Norris wrote:
>
> Hello internals,
>
> I have opened the vote for "Add persistent curl share handles":
> https://wiki.php.net/rfc/curl_share_persistence
>
> The vote will last for two weeks, until 2024-11-08 0:00 UTC.
>
>
Hello yet again internals,
I'd like to formally propose a continuation of the original error
backtraces RFC (https://wiki.php.net/rfc/error_backtraces):
https://wiki.php.net/rfc/error_backtraces_v2
We recently had a production incident that might have been shortened,
had we been able to identify
Hello,
I've opened the vote for "Persistent curl share handle improvement":
https://wiki.php.net/rfc/curl_share_persistence_improvement
I've added a week due to the holidays, so it will last for three
weeks, until 2025-01-02 0:00 UTC.
Thank you!
> Yes, I agree that having a stacktracke for fatal errors is a non-issue.
> For non-fatal errors the INI setting definitely is a problem.
> Unconditionally having a stacktrace for non-fatal errors I'm am not yet
> sure if this would be a problem or if it would be fine if it is a
> RFC-agreed-upon (
Hello,
We're nearing the two-week mark, so I'm curious if anyone has any
other feedback or points of discussion for this RFC.
In particular, I'm interested to know if anyone has thoughts on a
suggestion I had in one of the reply threads - that we could consider
something to the effect of allowing
On Mon, Dec 16, 2024 at 11:17 AM Eric Norris wrote:
>
> Hello,
>
> We're nearing the two-week mark, so I'm curious if anyone has any
> other feedback or points of discussion for this RFC.
>
> In particular, I'm interested to know if anyone has thoughts on a
&g
> Hi,
>
> Would be reasonable to be able to recover the stack trace of the error as a
> string, in addition to the proposed format? In general, it is the format I
> use in my error/exception handlers for convenience.
>
> A utility function that stringify the trace would be sufficient, as the
> o
On Thu, Dec 5, 2024 at 3:57 PM Eric Norris wrote:
>
> Hello yet again internals,
>
> I'd like to formally propose a continuation of the original error
> backtraces RFC (https://wiki.php.net/rfc/error_backtraces):
>
> https://wiki.php.net/rfc/error_backtraces_v2
>
&
Hello internals,
Apologies, I originally responded to the discussion thread instead of
starting a new thread.
As it has now been two weeks and discussion has quieted down, I've now
opened the "Error backtraces v2" RFC for voting:
https://wiki.php.net/rfc/error_backtraces_v2
Once again I've adde
Hello,
On Thu, Dec 5, 2024 at 5:31 PM Tim Düsterhus wrote:
>
> Hi
>
> Thank you for your RFC. This time I'm making sure to comment already
> during the discussion period :-)
Haha, thank you! I appreciate the feedback as always.
>
> On 12/5/24 21:57, Eric Norris wrote
On Thu, Dec 19, 2024 at 4:22 PM Eric Norris wrote:
>
> Hello internals,
>
> Apologies, I originally responded to the discussion thread instead of
> starting a new thread.
>
> As it has now been two weeks and discussion has quieted down, I've now
> opened the "E
On Wed, Dec 11, 2024 at 10:18 AM Eric Norris wrote:
>
> Hello,
>
> I've opened the vote for "Persistent curl share handle improvement":
>
> https://wiki.php.net/rfc/curl_share_persistence_improvement
>
> I've added a week due to the holidays, so it wil
Hello!
On Sun, Jun 15, 2025 at 1:33 PM Daniel Kesselberg
wrote:
>
> Hi,
>
> Thanks for all your feedback on the RFC.
>
> I've updated the RFC to incorporate most of your feedback:
> https://wiki.php.net/rfc/num_available_processors
>
> 1) The limitation, that the CPU affinity mask is ignored
> 2)
Thanks Rowan!
> I think calling it a "vision for a high-level API" is making it sound
> far more grandiose than what I suggested. What I suggested, and would
> still like to see, is a small number of additional methods, for setting
> really common options in a more user-friendly way.
I apologize
Thanks Larry!
> 1. I don't think the Curl\Option namespace is necessary. They can just be in
> the main Curl namespace.
I don't feel strongly here, but I thought it would be nice to group
the enums (if we go the multiple enum route) for discoverability.
Thoughts?
> 2. Please don't name the exc
On Thu, Jul 17, 2025 at 3:31 AM Rob Landers wrote:
>
> On Tue, Jul 15, 2025, at 19:27, Nicolas Grekas wrote:
>
>
>
> Le lun. 14 juil. 2025 à 15:41, Larry Garfield a
> écrit :
>
> On Sun, Jul 13, 2025, at 6:28 PM, Ilija Tovilo wrote:
> > Hi Nick
> >
> > On Fri, Jul 11, 2025 at 6:31 AM Nick wrote
Nick, Larry,
On Fri, Jul 18, 2025 at 2:01 PM Nicolas Grekas
wrote:
>
>
>
> Le ven. 18 juil. 2025 à 18:32, Tim Düsterhus a écrit :
>>
>> Hi
>>
>> On 7/17/25 18:26, Larry Garfield wrote:
>> > Given the lack of consensus both here and in off-list discussions on how
>> > to handle get hooks, we hav
On Wed, Jul 2, 2025 at 11:48 AM Eric Norris wrote:
>
> > Based on the feedback so far (I do plan on waiting for more responses
> > to your email), and on my own preferences, I wonder if there is a
> > hybrid option I could propose. Perhaps the RFC could offer both a
> &
> ** Deprecate the error_prepend_string and error_append_string INI directives
>Why is that of questionable use? Why is "this is a development and
> debugging feature" considered a valid reason to get rid of something? It
> allows prominently displaying issues in development when they would b
> An init hook would be clearer, certainly, though it also has its own edge
> cases. Can you set something that has an init hook? What happens if there's
> both a get and init hook? These probably have answers that could be sorted
> out, but that's a different question from "why the does a r
On Sun, Jul 13, 2025 at 2:00 PM Marc Bennewitz wrote:
>
>
> On 13.07.25 18:17, Nick wrote:
>
>
> On 13. Jul 2025, at 20:38, Marc Bennewitz wrote:
>
> Hi Nick, Claude,
>
> Hey Marc,
>
> I think it's important to explicitly mark it as "this value will be stored in
> memory", I mean just silently c
> Well, I don’t know. Everyone seems to think of init hooks (and their playing
> together with other hooks) differently.
> Some say this, some say that. That’s the exact issue. Want an example?
>
> Eric just agreed with your code example which has a get hook AND init hook.
>
> ```
> class Test {
>
On Wed, Jul 9, 2025 at 1:50 PM Larry Garfield wrote:
>
> On Wed, Jul 9, 2025, at 10:42 AM, Eric Norris wrote:
> >> An init hook would be clearer, certainly, though it also has its own edge
> >> cases. Can you set something that has an init hook? What happens if
>
> Based on the feedback so far (I do plan on waiting for more responses
> to your email), and on my own preferences, I wonder if there is a
> hybrid option I could propose. Perhaps the RFC could offer both a
> \Curl\Handle (tentative name) to address position 1, and a
> \Curl\BasicHttpHandle (also
Thanks for your response Ayesh! I hope to see this RFC on php.watch :)
> However, I softly oppose this RFC in its current state and the way it
> seems to be going.
>
> I have pushed Curl and libcurl to some uncommon cases such as HTTP/3,
> DoH, the new debug callback (which I authored the PR for),
> I'm not even sure it's a good idea to add those namespaced options: using
> CURLOPT_SSL_VERIFYHOST is perfect to find the corresponding curl
> documentation with your favorite search engine. php's doc is awesome, but it
> cannot compete with the details provided by curl's doc on the topic.
Th
> More specifically, since it does introduce an entirely new namespace it
> should be considered a “new extension” and must therefore follow the
> Exception policy outlined in:
> https://github.com/php/policies/blob/main/coding-standards-and-naming.rst#throwables
Embarrassingly, I had read your RF
Thanks for your thoughtful response, Larry! I agree with your summary.
> 1. Status quo is fine. PHP core not having a user-friendly way to send HTTP
> requests is acceptable. Maybe make Curl a little nicer, but only to make life
> easier for Guzzle et al.
> 2. We should develop the Curl API unti
> IMO, this sounds like something that would be great to start as a userland
> OOP wrapper for cURL, where it can be iterated on and the interface can be
> tested and changed much quicker. Then, maybe proceed to an external extension
> that can be migrated into core later, once its interface is
Hello Internals,
I'd like to formally propose a restart of the original object-oriented
curl API RFC (https://wiki.php.net/rfc/curl-oop):
https://wiki.php.net/rfc/curl_oop_v2
The prior RFC seemed to get positive feedback, with a small consensus
around wanting enum(s) for curl options. I've taken
On Fri, Jul 18, 2025 at 12:01 PM Rob Landers wrote:
>
>
>
> On Fri, Jul 18, 2025, at 17:25, Tim Düsterhus wrote:
>
> Hi
>
> On 7/14/25 15:38, Larry Garfield wrote:
> > Thanks, Ilija. You expressed my concerns as well. And yes, in practice,
> > readonly classes over-reaching is the main use case
On Sun, Jul 20, 2025 at 4:19 PM Rob Landers wrote:
>
>
>
> On Sun, Jul 20, 2025, at 19:18, Eric Norris wrote:
>
> Hi Rob,
>
> I'm going to respond to a few points from earlier emails here instead
> of each one.
>
> On Sat, Jul 19, 2025 at 6:13 AM Rob Landers
Hi Rob,
I'm going to respond to a few points from earlier emails here instead
of each one.
On Sat, Jul 19, 2025 at 6:13 AM Rob Landers wrote:
>
>
>
> On Sat, Jul 19, 2025, at 12:09, Claude Pache wrote:
>
>
>
> Le 19 juil. 2025 à 09:46, Rob Landers a écrit :
>
>
>
> On Sat, Jul 19, 2025, at 03:0
On Mon, Jul 21, 2025 at 10:47 AM Eric Norris wrote:
>
> On Mon, Jul 7, 2025 at 12:53 PM Eric Norris wrote:
> >
> > On Wed, Jul 2, 2025 at 11:48 AM Eric Norris wrote:
> > >
> > > > Based on the feedback so far (I do plan on waiting for more response
On Mon, Jul 7, 2025 at 12:53 PM Eric Norris wrote:
>
> On Wed, Jul 2, 2025 at 11:48 AM Eric Norris wrote:
> >
> > > Based on the feedback so far (I do plan on waiting for more responses
> > > to your email), and on my own preferences, I wonder if there is a
>
50 matches
Mail list logo
