Re: [users@httpd] Reverse proxy for app that only serves compressed content
On 10/9/20 6:15 PM, Nick Kew wrote: That would appear to be a bug. Indeed, a regression since I did extensive testing of the proxy and fixed a number of far-more-arcane bugs some years ago[1]. It seems implausible, and your test with curl seems to contradict it. I'm not sure I follow this, but note that the curl test was showing the behavior of the backend iDRAC, not the proxy. It also looks like questionable behaviour from the backend: if it's doing content negotiation (as implied by it reacting to Accept-Encoding) then this would seem to apply: It's a server BMC, so questionable (or worse) behavior is to be expected. -- In Soviet Russia, Google searches you! - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
Re: [users@httpd] Reverse proxy for app that only serves compressed content
On 10/9/20 2:21 PM, Nick Kew wrote: What do you want to happen? I need the proxy to include the Accept-Encoding header in the request that it sends to the server (and pass the compressed response back to the client). I *may* need the proxy to decompress the response if I need to do anything with mod_proxy_html. Currently, the client (browser) sends its request with an Accept- Encoding header, but the proxy's request to the server does not include that header, so the server returns a 404. -- In Soviet Russia, Google searches you! - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
[users@httpd] Reverse proxy for app that only serves compressed content
I am trying to configure httpd to reverse proxy a Dell iDRAC 8. The iDRAC will only respond to requests with gzip'ed content; i.e. it returns a 404 if the request does not include an 'Accept-Encoding: gzip' header. $ curl -v http://10.11.173.239/start.html 2>&1 | grep HTTP GET /start.html HTTP/1.1 < HTTP/1.1 404 Not Found $ curl -v -H 'Accept-Encoding: gzip' http://10.11.173.239/start.html 2>&1 | grep HTTP GET /start.html HTTP/1.1 < HTTP/1.1 200 OK I've found a number of articles about using the proxy to compress content on its way back to the client, but I can't find anything about proxying an application that serves up compressed content in the first place. I this possible? -- In Soviet Russia, Google searches you! - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
[users@httpd] Re: SSL virtual Hosts
On 06/09/2017 01:30 PM, Carlos Cruz wrote: I hope for my first question my questions isn’t too stupid but I haven’t been able to figured out my problem. My problem is I have about 10 virtual domains under the conf.d (Centos 6) directory with Apache HTTPD 2.2. SSL (only) virtual hosts don’t work if I used individual configuration files to define the virtual hosts. But all works as I understand it should work if I put all my SSL virtual hosts in 1 ssl.conf file in the same conf.d directory. can anyone tell me, or point me to the info, why multiple configuration files are not working for my SSL virtual hosts. 1 domain uses a wild card certificate The other domains use basic single domain certificates. I suspect that all domains are actually using the wildcard certificate when you use a single file. That's the only way that I can see this working. The SSL session is established *before* the client sends any HTTP request to the server, so the server has to choose which certificate to present to the client before it knows the hostname that the client is using. Thus, *named* virtual hosts don't work over SSL. (There's an extension called SNI that addresses this, but you didn't mention it, so I assume that you're not using it.) -- Ian Pilcher arequip...@gmail.com "I grew up before Mark Zuckerberg invented friendship" - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
[users@httpd] Why is AuthLDAPCompareAsUser discouraged?
I had to enable this option, because FreeIPA 4 doesn't make group membership visible to anonymous binds. The documentation for this option says: This directive should only be used when your LDAP server doesn't accept anonymous comparisons and you cannot use a dedicated AuthLDAPBindDN. I've been trying to think of a way in which creating an additional LDAP user, just for this purpose, and storing its password in cleartext in a configuration file is a better option. I can't come up with anything. Does anyone know why this option is discouraged? -- Ian Pilcher arequip...@gmail.com "I grew up before Mark Zuckerberg invented friendship" - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
