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_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? Regards, Graham --
