Re: [users@httpd] error 500 on POST request
Hi Andrija. In your logs I don't see the 500 error so maybe you cut and pasted the wrong log. But generally a 500 error means something fundamental went wrong and it might have nothing to do with Apache. If generally your python app works (Django is python under the covers right?) such as existing users able to log in and do stuff but only new user signup is broken... that leads me to believe that the python code is throwing a TypeError, ValueError, something like that. You'd better look at where the python/Django app is logging things out to get a clue there. It's most likely not an Apache configuration problem. If it was, all the existing users would be having issues. On Sun, Aug 11, 2024 at 2:05 PM Andrija Vranić wrote: > hi! > this has been killing me - when trying to register a new user in our > Django app (Arches), I am getting a 500 error code. > the logs > > he_shmcb_store (0x45 -> subcache 5) > [Sun Aug 11 17:43:11.492145 2024] [socache_shmcb:debug] [pid 1418627:tid > 127630808421952] mod_socache_shmcb.c(745): AH00842: expiring 2 and > reclaiming 0 removed socache entries > [Sun Aug 11 17:43:11.492146 2024] [socache_shmcb:debug] [pid 1418627:tid > 127630808421952] mod_socache_shmcb.c(765): AH00843: we now have 3 socache > entries > [Sun Aug 11 17:43:11.492148 2024] [socache_shmcb:debug] [pid 1418627:tid > 127630808421952] mod_socache_shmcb.c(862): AH00847: insert happened at > idx=82, data=(699:731) > [Sun Aug 11 17:43:11.492150 2024] [socache_shmcb:debug] [pid 1418627:tid > 127630808421952] mod_socache_shmcb.c(865): AH00848: finished insert, > subcache: idx_pos/idx_used=79/4, data_pos/data_used=167/710 > [Sun Aug 11 17:43:11.492151 2024] [socache_shmcb:debug] [pid 1418627:tid > 127630808421952] mod_socache_shmcb.c(530): AH00834: leaving > socache_shmcb_store successfully > [Sun Aug 11 17:43:11.492197 2024] [ssl:debug] [pid 1418627:tid > 127630808421952] ssl_engine_kernel.c(415): [client 172.31.25.238:45 > 64] AH02034: Initial (No.1) HTTPS request received for child 12 (server > suhozid.hr:443), referer: https://suhozid.hr/auth/signup, > origin-when-cross-origin > [Sun Aug 11 17:43:11.492230 2024] [authz_core:debug] [pid 1418627:tid > 127630808421952] mod_authz_core.c(815): [client 172.31.25.238:4564] > AH01626: authorization result of Require all granted: granted, referer: > https://suhozid.hr/auth/signup, origin-when-cross-origin > [Sun Aug 11 17:43:11.492233 2024] [authz_core:debug] [pid 1418627:tid > 127630808421952] mod_authz_core.c(815): [client 172.31.25.238:4564] > AH01626: authorization result of : granted, referer: > https://suhozid.hr/auth/signup, origin-when-cross-origin > [Sun Aug 11 17:43:11.492258 2024] [authz_core:debug] [pid 1418627:tid > 127630808421952] mod_authz_core.c(815): [client 172.31.25.238:4564] > AH01626: authorization result of Require all granted: granted, referer: > https://suhozid.hr/auth/signup, origin-when-cross-origin > [Sun Aug 11 17:43:11.492260 2024] [authz_core:debug] [pid 1418627:tid > 127630808421952] mod_authz_core.c(815): [client 172.31.25.238:4564] > AH01626: authorization result of : granted, referer: > https://suhozid.hr/auth/signup, origin-when-cross-origin > [Sun Aug 11 17:43:11.564318 2024] [ssl:debug] [pid 1418627:tid > 127630808421952] ssl_engine_io.c(1147): [client 172.31.25.238:4564] > AH02001: Connection closed to child 12 with standard shutdown (server > suhozid.hr:443) >
Re: [users@httpd] error 500 on POST request
thank you Aaron! On Mon, 12 Aug 2024 at 17:15, Aaron Rosenzweig wrote: > Hi Andrija. In your logs I don't see the 500 error so maybe you cut and > pasted the wrong log. But generally a 500 error means something fundamental > went wrong and it might have nothing to do with Apache. If generally your > python app works (Django is python under the covers right?) such as > existing users able to log in and do stuff but only new user signup is > broken... that leads me to believe that the python code is throwing a > TypeError, ValueError, something like that. You'd better look at where the > python/Django app is logging things out to get a clue there. It's most > likely not an Apache configuration problem. If it was, all the existing > users would be having issues. > > On Sun, Aug 11, 2024 at 2:05 PM Andrija Vranić > wrote: > >> hi! >> this has been killing me - when trying to register a new user in our >> Django app (Arches), I am getting a 500 error code. >> the logs > >> he_shmcb_store (0x45 -> subcache 5) >> [Sun Aug 11 17:43:11.492145 2024] [socache_shmcb:debug] [pid 1418627:tid >> 127630808421952] mod_socache_shmcb.c(745): AH00842: expiring 2 and >> reclaiming 0 removed socache entries >> [Sun Aug 11 17:43:11.492146 2024] [socache_shmcb:debug] [pid 1418627:tid >> 127630808421952] mod_socache_shmcb.c(765): AH00843: we now have 3 socache >> entries >> [Sun Aug 11 17:43:11.492148 2024] [socache_shmcb:debug] [pid 1418627:tid >> 127630808421952] mod_socache_shmcb.c(862): AH00847: insert happened at >> idx=82, data=(699:731) >> [Sun Aug 11 17:43:11.492150 2024] [socache_shmcb:debug] [pid 1418627:tid >> 127630808421952] mod_socache_shmcb.c(865): AH00848: finished insert, >> subcache: idx_pos/idx_used=79/4, data_pos/data_used=167/710 >> [Sun Aug 11 17:43:11.492151 2024] [socache_shmcb:debug] [pid 1418627:tid >> 127630808421952] mod_socache_shmcb.c(530): AH00834: leaving >> socache_shmcb_store successfully >> [Sun Aug 11 17:43:11.492197 2024] [ssl:debug] [pid 1418627:tid >> 127630808421952] ssl_engine_kernel.c(415): [client 172.31.25.238:45 >> 64] AH02034: Initial (No.1) HTTPS request received for child 12 (server >> suhozid.hr:443), referer: https://suhozid.hr/auth/signup, >> origin-when-cross-origin >> [Sun Aug 11 17:43:11.492230 2024] [authz_core:debug] [pid 1418627:tid >> 127630808421952] mod_authz_core.c(815): [client 172.31.25.238:4564] >> AH01626: authorization result of Require all granted: granted, referer: >> https://suhozid.hr/auth/signup, origin-when-cross-origin >> [Sun Aug 11 17:43:11.492233 2024] [authz_core:debug] [pid 1418627:tid >> 127630808421952] mod_authz_core.c(815): [client 172.31.25.238:4564] >> AH01626: authorization result of : granted, referer: >> https://suhozid.hr/auth/signup, origin-when-cross-origin >> [Sun Aug 11 17:43:11.492258 2024] [authz_core:debug] [pid 1418627:tid >> 127630808421952] mod_authz_core.c(815): [client 172.31.25.238:4564] >> AH01626: authorization result of Require all granted: granted, referer: >> https://suhozid.hr/auth/signup, origin-when-cross-origin >> [Sun Aug 11 17:43:11.492260 2024] [authz_core:debug] [pid 1418627:tid >> 127630808421952] mod_authz_core.c(815): [client 172.31.25.238:4564] >> AH01626: authorization result of : granted, referer: >> https://suhozid.hr/auth/signup, origin-when-cross-origin >> [Sun Aug 11 17:43:11.564318 2024] [ssl:debug] [pid 1418627:tid >> 127630808421952] ssl_engine_io.c(1147): [client 172.31.25.238:4564] >> AH02001: Connection closed to child 12 with standard shutdown (server >> suhozid.hr:443) >> >
[users@httpd] Re: mod_proxy health check custom header
Does anyone have advice for me regarding custom headers in mod_proxy health check? Thank you :-) On Wed, Aug 7, 2024 at 2:31 PM Aaron Rosenzweig wrote: > We have mod_proxy doing balancing and working great with the exception of > one thing, the health check. I'm talking about the heartbeat interval that > tells mod_proxy if our java app instances are ok. > > I read the docs here: > https://httpd.apache.org/docs/current/mod/mod_proxy_hcheck.html > > I'm pretty sure the issue is that the health check is not picking up the > custom header I need to talk to a WebObjects application (java). I'm > wondering if there is a way to configure it or if it simply isn't possible > and am looking for advice on appending this header. > > When setting up the proxy balancer, I initially had the same problem but > it was quickly solved by adding the following line before the proxy > balancer definition: > RequestHeader append x-webobjects-adaptor-version "mod_proxy" > > What that did was add an arcane header that the java app (NeXT/Apple > WebObjects) instances need to see in order for them to want to respond. > Without it, they will drop the connection. Essentially what I'm doing here > is replacing a special mod_webobjects Apache module with the built-in > mod_proxy. This header is just something WO needs to see to allow > communication. > > But now, when I add health check parameters to the proxy balancer it > thinks the app instances are all dead. It's because, for some reason, the > custom header is not being used for the health check and the connection > immediately drops. To confirm that was true, I modified the java > application to force the header to be set when an incoming java HTTP > request was received. While that did allow communication with health check, > it causes other problems for me so is not a good workaround. > > Does anyone know how to configure the mod_proxy health check to use a > custom header? Or is it not possible currently? Thank you :-) >
Re: [users@httpd] mod_proxy health check custom header
> Does anyone know how to configure the mod_proxy health check to use a custom > header? Or is it not possible currently? Thank you :-) Not a user but I checked the code and I don't think it's possible without an enhancement to mod_proxy_hcheck. The change would not be too bad though. https://github.com/apache/httpd/blob/trunk/modules/proxy/mod_proxy_hcheck.c#L429 would just need to pass something configured into r->headers_in. The only minor complication is that the similar config in mod_proxy_hcheck actual lives more genericly in the proxy_worker config of mod_proxy. > I modified the java application to force the header to be set when an > incoming java HTTP request was received. While that did allow communication > with health check, it causes other problems for me so is not a good > workaround. Could you do the above only for a specific URL and then use hcuri= to use it from the healthcheck? Or does it not dodge the other problems? -- Eric Covener cove...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
Re: [users@httpd] mod_proxy health check custom header
Hi Eric thanks for digging into code to confirm what I was asking for isn't currently possible. Sounds like while it might be a reasonable enhancement, and somewhat easy to implement, it's not a slam dunk because it could have complications. Yes, you are right, by checking for a particular endpoint or perhaps other details in the incoming request/header we could have a more targeted workaround in our java application. That's probably what we'll need to do at least for now :-) Thanks for getting back to me. On Mon, Aug 12, 2024 at 2:53 PM Eric Covener wrote: > > Does anyone know how to configure the mod_proxy health check to use a > custom header? Or is it not possible currently? Thank you :-) > > Not a user but I checked the code and I don't think it's possible > without an enhancement to mod_proxy_hcheck. The change would not be > too bad though. > > > https://github.com/apache/httpd/blob/trunk/modules/proxy/mod_proxy_hcheck.c#L429 > would just need to pass something configured into r->headers_in. > The only minor complication is that the similar config in > mod_proxy_hcheck actual lives more genericly in the proxy_worker > config of mod_proxy. > > > I modified the java application to force the header to be set when an > incoming java HTTP request was received. While that did allow communication > with health check, it causes other problems for me so is not a good > workaround. > > Could you do the above only for a specific URL and then use hcuri= to > use it from the healthcheck? Or does it not dodge the other problems? > > -- > Eric Covener > cove...@gmail.com > > - > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > >
[users@httpd] Problem Configuring httpd 2.4 to allow expired client certficates
I am working on migrating an application to httpd 2.4 on AL2023. The application uses client certificates, which will be expiring before they can all be rotated with new expirations. I am attempting to configure httpd 2.4 to continue requiring client certificates, but change the configuration to accept them if they are expired. I have not been able to figure out how to accept expired client certificates, however, I did find some info from the following: https://blog.fem.tu-ilmenau.de/archives/1025-Accepting-expired-client-certificates-with-apache-2.4.html I tried the method suggested and built the shared library mysslverify.so, and placed the drop in service mysslverify.conf at /etc/systemd/system/httpd.service.d with contents: [Service]Environment="LD_PRELOAD=/etc/httpd/conf/mysslverify.so" To reload the service file and restart httpd I issued: $ systemctl daemon-reload$ systemctl restart httpd For which there were no errors, and I confirmed mysslverify.so was loaded as follows: $ ps aux | grep httpdroot 347549 0.8 0.1 35256 15144 ? Ss 23:34 0:00 /usr/sbin/httpd -DFOREGROUNDapache 347558 0.0 0.0 46212 5300 ? S 23:34 0:00 /usr/sbin/httpd -DFOREGROUNDapache 347559 0.0 0.1 1572936 8620 ? Sl 23:34 0:00 /usr/sbin/httpd -DFOREGROUNDapache 347560 0.0 0.1 1572936 8640 ? Sl 23:34 0:00 /usr/sbin/httpd -DFOREGROUNDapache 347561 0.0 0.1 1736840 8684 ? Sl 23:34 0:00 /usr/sbin/httpd -DFOREGROUNDroot 347738 0.0 0.0 222312 2156 pts/5 S+ 23:34 0:00 grep --color=auto httpd$ cat /proc/347549/maps | grep mysslverify.so7fec37187000-7fec37188000 r--p 103:01 226492593 /etc/httpd/conf/mysslverify.so7fec37188000-7fec37189000 r-xp 1000 103:01 226492593 /etc/httpd/conf/mysslverify.so7fec37189000-7fec3718a000 r--p 2000 103:01 226492593 /etc/httpd/conf/mysslverify.so7fec3718a000-7fec3718b000 r--p 2000 103:01 226492593 /etc/httpd/conf/mysslverify.so7fec3718b000-7fec3718c000 rw-p 3000 103:01 226492593 /etc/httpd/conf/mysslverify.so After making this configuration change, expired certificates continued to be rejected.Issuing the openssl s_client command to test results in: 003E67F4887F:error:0A000415:SSL routines:ssl3_read_bytes:sslv3 alert certificate expired:ssl/record/rec_layer_s3.c:1605:SSL alert number 45 Clients using non-expired certificates can connect ok. Also, at https://httpd.apache.org/support.html , I repeatedly attempted to go to the "archives" link that we are supposed to consult before posting. However, clicking on that link resulted in the error: httpd.markmail.ort took too long to respond (ERR_CONNECTION_TIMED_OUT). I found another link to the archive that is http://mail-archives.apache.org/mod_mbox/httpd-users/ , and that results in error too:mail-archives.apache.org took too long to respond (ERR_TIMED_OUT). Please advise on how I can get expired client certificates to be accepted by an httpd 2.4 server running on AL2023.
