Re: Fwd: [users@httpd] SNI with apache 2.4.1 reverse proxy
On 07.04.2012 00:34, Daniel Ruggeri wrote: I wanted to bring this up here - seems like a few things are going on that are confusing to me. I'll try to look into it when time becomes available, but I thought someone might have an opinion off the bat. Original Message Subject: [users@httpd] SNI with apache 2.4.1 reverse proxy Date: Fri, 6 Apr 2012 14:11:50 +0200 From: Michael Weiser mich...@dinsnail.net Reply-To: us...@httpd.apache.org To: us...@httpd.apache.org [...] [Fri Apr 06 11:23:55 2012] [error] Hostname www.example.com provided via SNI and hostname subdomain.example.com provided via HTTP are different Seems like mod_ssl is not getting the proper host name in the proxy-request-hostname note... from a quick glance at the working HTTPS reverse proxy configuration of httpd 2.2, he is obviously trying to forward the whole domain to port 12443 on the same machine (note the *.example.com ServerAlias): VirtualHost *:443 DocumentRoot /var/www/www.example.com ServerName www.example.com ServerAlias example.com *.example.com [...] ProxyPass / https://www.example.com:12443/ ProxyPassReverse / https://www.example.com:12443/ Then it looks like mod_proxy_http determines the value for proxy-request-hostname from the remote URL in ProxyPass, but is passing on the Host header from the original request. Kaspar
utf-8 - punycode for ServerName|Alias?
So we have live registrars, no longer experimental, who are now registering domains in punycode. Make of it what you will. Do we want to recognize non-ASCII strings in the ServerName|Alias directives as utf-8 - punycode encodings? Internally, from the time the servername field is assigned, it can be an ascii mapping. All thoughts appreciated, particularly references to fresh specs, implementation guidance and compatible clients.
Re: utf-8 - punycode for ServerName|Alias?
Am 07.04.2012 08:33, schrieb William A. Rowe Jr.: So we have live registrars, no longer experimental, who are now registering domains in punycode. Make of it what you will. Do we want to recognize non-ASCII strings in the ServerName|Alias directives as utf-8 - punycode encodings? Internally, from the time the servername field is assigned, it can be an ascii mapping. All thoughts appreciated, particularly references to fresh specs, implementation guidance and compatible clients. serverconfigs - punnycode dns in background - punnycode self written backends - input UTF8, transparent translation while generating serverconfigs and translate back for display nothing other happens if you make nslookup würmlach.at there is no ü in any configuration nor in EPP/DRI nor in any postfix/dbmail/dovecot configuration [harry@srv-rhsoft:~]$ nslookup würmlach.at ns1.thelounge.net Server: ns1.thelounge.net Address:85.124.176.242#53 Name: würmlach.at Address: 91.118.73.6 signature.asc Description: OpenPGP digital signature
Re: utf-8 - punycode for ServerName|Alias?
T Sent from my BlackBerry® smartphone -Original Message- From: Reindl Harald h.rei...@thelounge.net Date: Sat, 07 Apr 2012 11:00:16 To: dev@httpd.apache.org Reply-To: dev@httpd.apache.org Subject: Re: utf-8 - punycode for ServerName|Alias? Am 07.04.2012 08:33, schrieb William A. Rowe Jr.: So we have live registrars, no longer experimental, who are now registering domains in punycode. Make of it what you will. Do we want to recognize non-ASCII strings in the ServerName|Alias directives as utf-8 - punycode encodings? Internally, from the time the servername field is assigned, it can be an ascii mapping. All thoughts appreciated, particularly references to fresh specs, implementation guidance and compatible clients. serverconfigs - punnycode dns in background - punnycode self written backends - input UTF8, transparent translation while generating serverconfigs and translate back for display nothing other happens if you make nslookup würmlach.at there is no ü in any configuration nor in EPP/DRI nor in any postfix/dbmail/dovecot configuration [harry@srv-rhsoft:~]$ nslookup würmlach.at ns1.thelounge.net Server: ns1.thelounge.net Address:85.124.176.242#53 Name: würmlach.at Address: 91.118.73.6
Re: utf-8 - punycode for ServerName|Alias?
On 7 Apr 2012, at 07:33, William A. Rowe Jr. wrote: So we have live registrars, no longer experimental, who are now registering domains in punycode. Make of it what you will. Do we want to recognize non-ASCII strings in the ServerName|Alias directives as utf-8 - punycode encodings? Internally, from the time the servername field is assigned, it can be an ascii mapping. I think this is more important for mass virtual hosting (VirtualDocumentRoot from mod_vhost_alias, etc). Users would create a document root directory named, eg, テスト.example and expect it to work. They don't know anything about Unicode, let alone punycode. I reckon a lot of users would work out quickly that only Roman characters work in domain names, but they aren't going to be able to work out how to rename that folder into the correct punycode nor to tell the folders apart if renamed in this way. As a user: I already have a configuration file with a UTF-8 ServerAlias defined, that's just waiting for httpd to implement this feature … and until then, I have the punycoded version in there as well. -- Tim Bannister – is...@jellybaby.net smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] Release Apache httpd 2.4.2 as GA
[X] +1: Good to go +1 on AIX / xlc / PPC64, no regressions. (100% other than SSL, not normally loaded on my AIX regression)
Re: [VOTE] Release Apache httpd 2.4.2 as GA
Tested and used by quite some users at AL. All building and running good on all the flavors (Win32 and Win64 with VC9 and VC10). Build with IPv6 and Crypto enabled and the deps: apr-1.4.6 (patched) apr-util-1.4.1 apr-iconv-1.2.1 openssl-1.0.1-and-0.9.8u zlib-1.2.6 pcre-8.30 libxml2-2.7.8 lua-5.1.5 expat-2.1.0 Steffen ps, The AcceptFilter none is still an issue, as reported. -Original Message- From: Jim Jagielski Sent: Thursday, April 05, 2012 2:24 PM Newsgroups: gmane.comp.apache.devel To: dev@httpd.apache.org Subject: [VOTE] Release Apache httpd 2.4.2 as GA The pre-release test tarballs for Apache httpd 2.4.2 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.4.2 GA. NOTE: The -deps tarballs are included here *only* to make life easier for the tester. They will not be, and are not, part of the official release. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. Vote will last the normal 72 hrs.
Re: mod_proxy problem with APC on the backend
Actually since I found that restarting the heavy side let it work once, I
focused more on that and the second time I do wget I get:
--2012-04-07 19:14:25-- (try:11) http://example.com:8080/test.php
Connecting to example.com|127.0.0.1|:8080... connected.
HTTP request sent, awaiting response... No data received.
Retrying.
It did that 11 times until I canceled it.
Also in the global logs I now see:
[Sat Apr 07 19:21:15 2012] [notice] child pid 32687 exit signal Segmentation
fault (11)
[Sat Apr 07 19:21:16 2012] [notice] child pid 2378 exit signal Segmentation
fault (11)
[Sat Apr 07 19:21:19 2012] [notice] child pid 2379 exit signal Segmentation
fault (11)
[Sat Apr 07 19:21:20 2012] [notice] child pid 2381 exit signal Segmentation
fault (11)
[Sat Apr 07 19:21:33 2012] [notice] child pid 2382 exit signal Segmentation
fault (11)
-Will
- Original Message -
From: Will
To: dev@httpd.apache.org
Sent: Saturday, April 07, 2012 6:58 PM
Subject: mod_proxy problem with APC on the backend
With a light httpd worker front end as a reverse proxy to a mod_php backend
everything works fine, until I enable APC for PHP on the backend. If I use
wget to make a request to the backend directly, it works fine. If I restart
the httpd backend, it works for one request from the light side, then fails
with:
Proxy Error
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /test.php.
Reason: Error reading from remote server
Logs show:
[Sat Apr 07 10:09:02 2012] [error] [client 10.9.8.7] (70014)End of file
found: proxy: error reading status line from remote server 127.0.0.1:8080
[Sat Apr 07 10:09:02 2012] [error] [client 10.9.8.7] proxy: Error reading
from remote server returned by /test.php
Is this similar to your bug report?
http://mail-archives.apache.org/mod_mbox/httpd-dev/201201.mbox/%3c4f25b7b3.6050...@kippdata.de%3E
You can see my full config without the actual vhost here:
https://github.com/shazarlx/kloxo/tree/httpd-light_2/kloxo/file/httpd-light
The vhost contains:
IfDefine light
ProxyPassReverse / http://127.0.0.1:8080/
RewriteEngine on
RewriteCond %{REQUEST_URI} .*\.(php)$
RewriteRule ^/(.*) http://127.0.0.1:8080/$1 [P]
/IfDefine
Also I've switched the heavy side to prefork from itk but still the same
results.
-Will
Re: mod_proxy problem with APC on the backend
On Sat, Apr 7, 2012 at 6:58 PM, Will william.leon...@lxcenter.org wrote: With a light httpd worker front end as a reverse proxy to a mod_php backend everything works fine, until I enable APC for PHP on the backend. Off-topic here, maybe you can find some advice on a PHP list or http://httpd.apache.org/lists.html#http-users http://httpd.apache.org/dev/debugging.html
