Den tis 22 juli 2025 kl 12:51 skrev Branko Čibej <br...@apache.org>:
> On 22. 7. 25 11:08, Graham Leggett wrote: > > On 22 Jul 2025, at 08:23, Daniel Sahlberg<daniel.l.sahlb...@gmail.com> > wrote: > > > >> I like the idea of having a sub_status. It might not make much sense to > a > >> random user, but for debugging purposes it might be useful. Of course it > >> would be nice to match any subsystem error to proper SERF errors, but > maybe > >> it doesn't make sense to replicate EVERY error code that could happen. > >> Maybe it is enough to know there was an error in loading an SSL > certificate > >> and we can then look up the sub_status in OpenSSL's error code. (We do > this > >> at $dayjob, our system vendor is returning an error code for "database > >> error" and the subcode can then be referenced in the database vendor's > >> error code listing). > > In APR-util we return the underlying code, and the underlying string > that matches that code, generated by the underlying library. > > > > The cost of obscuring that underlying error string is immense. Instead > of instantly knowing the reason for the failure, in my case I contacted a > vendor, who then gave a long list of possible reasons for the problem (but > not the actual reason), which was impossible to diagnose without a > debugger. We need to have the most specific error easily accessible to the > end user, so the vendor gives exactly one answer. > > > > https://github.com/apache/apr/blob/trunk/include/apu_errno.h#L418 > > > >> I tried to follow the code and I can't figure out if there is a place > where > >> we can store the callback function pointer, except in the > >> serf_ssl_context_t, just like it is done right now. > > This was the problem I had, there was nowhere else to put the callback. > > > > In httpd there is a clear hierarchy, if you have a request_rec in your > hand, you can access the conn_rec above, the server_rec, and so on. There > does not appear to be the same in serf. > > > Serf has a clear hierarchy, too: context -> connection -> request/response. > > > > serf_ssl_context_t represents a single SSL connection, but that > structure contains no parent reference to the connection itself. > > > > I'm assuming this is reasonably straightforward to fix? > > We should add a link back to the parent serf_connection_t (which already > links back to the serf_context_t). The error struct should have pointers > to all three, context, connection and request (when available). > > > The callback should be registered on the context, as that's the unit of > thread isolation in Serf -- you must not use the same context > simultaneously from different threads, so we know that any callbacks are > triggered synchronously with serf_context_run() or similar. > > > The only problem is that error info may live longer than those objects, > so users MUST NOT stash those pointers "for later". We could solve that > by careful use of pool cleanups, but I'd prefer to make the > documentation extremely clear about those limitations. > > > -- Brane > I can't quite figure out how the object hierachy is created. It seems the serf_ssl_context_t is created quite "by itself". @Branko Čibej <br...@apache.org> Can you give me some hints where to start to add this backlink? Cheers, Daniel
