Re: [users@httpd] httpd-2.4.25 compile fail
Afaik httpd 2.4 is not yet compatible with openssl 1.1.x, the max version you can use is 1.0.2x. 2016-12-27 1:24 GMT+01:00 Kent Frazier : > I'm trying (unsuccessfully) to build on a Mac Pro version 10.12.2 > (Sierra Darwin Kernel Version 16.3.0) > > libtool (GNU libtool) 2.4 > > OpenSSL 1.1.0c 10 Nov 2016 > > /usr/local/apr/build-1/libtool --silent --mode=link > /Applications/Xcode.app/Contents/Developer/Toolchains/ > XcodeDefault.xctoolchain/usr/bin/cc > -g -O2 -L/usr/local/lib -lssl -lcrypto -lpthread \ > -o ab ab.lo /usr/local/apr/lib/libaprutil-1.la > -lexpat -liconv /usr/local/apr/lib/libapr-1.la -lpthread > Undefined symbols for architecture x86_64: > "_CRYPTO_malloc_init", referenced from: > _main in ab.o > "_SSLv2_client_method", referenced from: > _main in ab.o > ld: symbol(s) not found for architecture x86_64 > > anybody know what's going on? > > > - > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > > -- *Daniel Ferradal* IT Specialist email dferradal at gmail.com linkedin es.linkedin.com/in/danielferradal
Re: [users@httpd] httpd-2.4.25 compile fail
maybe, have a look on how Arnaud Icard solved his compilation problem on a Mac (october 18 2015) http://httpd.markmail.org/search/?q=aterrestris#query:aterrestris+page:1+mid:jp2j7dr4kkwrokz7+state:results 2016-12-27 10:34 GMT+01:00 Daniel : > Afaik httpd 2.4 is not yet compatible with openssl 1.1.x, the max version > you can use is 1.0.2x. > > 2016-12-27 1:24 GMT+01:00 Kent Frazier : > >> I'm trying (unsuccessfully) to build on a Mac Pro version 10.12.2 >> (Sierra Darwin Kernel Version 16.3.0) >> >> libtool (GNU libtool) 2.4 >> >> OpenSSL 1.1.0c 10 Nov 2016 >> >> /usr/local/apr/build-1/libtool --silent --mode=link >> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeD >> efault.xctoolchain/usr/bin/cc >> -g -O2 -L/usr/local/lib -lssl -lcrypto -lpthread \ >> -o ab ab.lo /usr/local/apr/lib/libaprutil-1.la >> -lexpat -liconv /usr/local/apr/lib/libapr-1.la -lpthread >> Undefined symbols for architecture x86_64: >> "_CRYPTO_malloc_init", referenced from: >> _main in ab.o >> "_SSLv2_client_method", referenced from: >> _main in ab.o >> ld: symbol(s) not found for architecture x86_64 >> >> anybody know what's going on? >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org >> For additional commands, e-mail: users-h...@httpd.apache.org >> >> > > > -- > *Daniel Ferradal* > IT Specialist > > email dferradal at gmail.com > linkedin es.linkedin.com/in/danielferradal >
[users@httpd] Web sockets & proxypass - No protocol handler was valid for the URL
Hi! I've been trying to setup a reverse proxy to a localhost websocket url. ProxyPass /chat/stream/ wss://localhost:8000/chat/stream/ ProxyPassReverse /chat/stream/ wss://localhost:8000/chat/stream/ I get an error in the apache error_log that reads: No protocol handler was valid for the URL /chat/stream/. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule. I have read a lot of pages via google of people using this method so I wonder if there is some issue in our setup/install of Apache that ships with Mac OS X 10.11 & Server.app 5.2? I have all the standard modules loaded in httpd_server_app.conf LoadModule proxy_module libexec/apache2/mod_proxy.so LoadModule proxy_http_module libexec/apache2/mod_proxy_http.so LoadModule proxy_wstunnel_module libexec/apache2/mod_proxy_wstunnel.so When I access the application running on localhost:8000 directly on the server everything works fine Any ideas what could be going on? Thanks! Adam Apache 2.4.18, Mac OS X 10.11, Server.app 5.2
Re: [users@httpd] Web sockets & proxypass - No protocol handler was valid for the URL
Silly question perhaps, are you also loading mod_ssl? 2016-12-27 14:39 GMT+01:00 Adam Teale : > Hi! > > I've been trying to setup a reverse proxy to a localhost websocket url. > > ProxyPass /chat/stream/ wss://localhost:8000/chat/stream/ > ProxyPassReverse /chat/stream/ wss://localhost:8000/chat/stream/ > > I get an error in the apache error_log that reads: > > No protocol handler was valid for the URL /chat/stream/. If you are using > a DSO version of mod_proxy, make sure the proxy submodules are included in > the configuration using LoadModule. > > I have read a lot of pages via google of people using this method so I > wonder if there is some issue in our setup/install of Apache that ships > with Mac OS X 10.11 & Server.app 5.2? > > I have all the standard modules loaded in httpd_server_app.conf > > LoadModule proxy_module libexec/apache2/mod_proxy.so > LoadModule proxy_http_module libexec/apache2/mod_proxy_http.so > LoadModule proxy_wstunnel_module libexec/apache2/mod_proxy_wstunnel.so > > When I access the application running on localhost:8000 directly on the > server everything works fine > > Any ideas what could be going on? > > Thanks! > > Adam > Apache 2.4.18, Mac OS X 10.11, Server.app 5.2 > -- *Daniel Ferradal* IT Specialist email dferradal at gmail.com linkedin es.linkedin.com/in/danielferradal
Re: [users@httpd] Web sockets & proxypass - No protocol handler was valid for the URL
Hi Daniel, Yes in the http_server_app.conf file it is activated: LoadModule ssl_module libexec/apache2/mod_ssl.so It is interesting though that when I run an "sudo apachectl -M" i can't see ssl_module in there.
Re: [users@httpd] Web sockets & proxypass - No protocol handler was valid for the URL
Check this link out. http://stackoverflow.com/questions/17889676/apache-2-4-6-reverseproxy-mod-proxy-wstunnel-for-secure-websocket-wss-fails Thanks, Otis On Tue, Dec 27, 2016 at 8:55 AM, Daniel wrote: > Silly question perhaps, are you also loading mod_ssl? > > 2016-12-27 14:39 GMT+01:00 Adam Teale : > >> Hi! >> >> I've been trying to setup a reverse proxy to a localhost websocket url. >> >> ProxyPass /chat/stream/ wss://localhost:8000/chat/stream/ >> ProxyPassReverse /chat/stream/ wss://localhost:8000/chat/stream/ >> >> I get an error in the apache error_log that reads: >> >> No protocol handler was valid for the URL /chat/stream/. If you are using >> a DSO version of mod_proxy, make sure the proxy submodules are included in >> the configuration using LoadModule. >> >> I have read a lot of pages via google of people using this method so I >> wonder if there is some issue in our setup/install of Apache that ships >> with Mac OS X 10.11 & Server.app 5.2? >> >> I have all the standard modules loaded in httpd_server_app.conf >> >> LoadModule proxy_module libexec/apache2/mod_proxy.so >> LoadModule proxy_http_module libexec/apache2/mod_proxy_http.so >> LoadModule proxy_wstunnel_module libexec/apache2/mod_proxy_wstunnel.so >> >> When I access the application running on localhost:8000 directly on the >> server everything works fine >> >> Any ideas what could be going on? >> >> Thanks! >> >> Adam >> Apache 2.4.18, Mac OS X 10.11, Server.app 5.2 >> > > > > -- > *Daniel Ferradal* > IT Specialist > > email dferradal at gmail.com > linkedin es.linkedin.com/in/danielferradal >
Re: [users@httpd] Web sockets & proxypass - No protocol handler was valid for the URL
You can also check this URL: http://blog.revathskumar.com/2015/09/proxy-websocket-via-apache.html Thanks, Otis On Tue, Dec 27, 2016 at 9:07 AM, Adam Teale wrote: > Hi Daniel, > > Yes in the http_server_app.conf file it is activated: > LoadModule ssl_module libexec/apache2/mod_ssl.so > > It is interesting though that when I run an "sudo apachectl -M" i can't > see ssl_module in there. > > > >
Re: [users@httpd] Web sockets & proxypass - No protocol handler was valid for the URL
I have upgraded to MacOS 10.12 so now Apache 2.4.23 is the current version. Either way the patch that was suggested was supposed to have been included in 2.4.10. 2016-12-27 11:29 GMT-03:00 Adam Teale : > Otis do you know if it pretty straightforward to apply a patch to an > apache module? > > 2016-12-27 11:28 GMT-03:00 Adam Teale : > >> Hi Otis thanks for looking into it for me. >> The link to revathskumar's blog is pretty much what I have setup at the >> moment. I'll check out the bug report! Thanks! >> >> 2016-12-27 11:23 GMT-03:00 Otis Dewitt - NOAA Affiliate < >> otis.dew...@noaa.gov>: >> >>> You can also check this URL: http://blog.revathskumar. >>> com/2015/09/proxy-websocket-via-apache.html >>> >>> Thanks, >>> Otis >>> >>> On Tue, Dec 27, 2016 at 9:07 AM, Adam Teale wrote: >>> Hi Daniel, Yes in the http_server_app.conf file it is activated: LoadModule ssl_module libexec/apache2/mod_ssl.so It is interesting though that when I run an "sudo apachectl -M" i can't see ssl_module in there. >>> >>> >> >
Re: [users@httpd] Web sockets & proxypass - No protocol handler was valid for the URL
Perhaps something useful - I do see that the "serveradmin" command says that it runs apache 2.2 even though "httpd -v" says 2.4.23?? httpd -v Server version: Apache/2.4.23 (Unix) Server built: Aug 8 2016 16:31:34 sudo serveradmin fullstatus web web:health = _empty_dictionary web:readWriteSettingsVersion = 1 web:apacheVersion = "2.2" web:servicePortsRestrictionInfo = _empty_array web:startedTime = "2016-12-27 19:08:59 +" web:apacheState = "RUNNING" web:statusMessage = "" web:ApacheMode = 2 web:servicePortsAreRestricted = "NO" web:state = "STOPPED" web:setStateVersion = 1
[users@httpd] Why ExpiresByType is ignored when has SetHandler application/x-httpd-php ?
בע"ה Why ExpiresByType is ignored when has SetHandler application/x-httpd-php ? /sitemap.xml Response Headers shows 1 day expiration while expected to be 1 year (1 month) Content-Type: application/xml; charset=utf-8 Date: Tue, 27 Dec 2016 19:59:00 GMT Expires: Wed, 28 Dec 2016 19:59:00 GMT seems SetHandler forces it to apply text/html expiration and doesn't allow to rewrite it ExpiresActive On ExpiresDefault"access plus 1 month" ExpiresByType text/html "access plus 1 day" ExpiresByType application/xml "access plus 1 week" SetHandler application/x-httpd-php Header set Content-Type "application/xml" ExpiresDefault "access plus 1 year" tested on Apache 2.4.X builds. How to fix this issue? Binyamin
Re: [users@httpd] Why ExpiresByType is ignored when has SetHandler application/x-httpd-php ?
It might have something to do with the order the modules handle the request. What happens if you tell PHP to set the content type to application/xml? - Y On Tue, Dec 27, 2016 at 3:55 PM, Binyamin <7rai...@inbox.lv> wrote: > בע"ה > > > Why ExpiresByType is ignored when has SetHandler application/x-httpd-php ? > > /sitemap.xml Response Headers shows 1 day expiration while expected to be > 1 year (1 month) > > Content-Type: application/xml; charset=utf-8 > Date: Tue, 27 Dec 2016 19:59:00 GMT > Expires: Wed, 28 Dec 2016 19:59:00 GMT > > seems SetHandler forces it to apply text/html expiration and doesn't allow > to rewrite it > > ExpiresActive On > ExpiresDefault"access plus 1 month" > ExpiresByType text/html "access plus 1 day" > ExpiresByType application/xml "access plus 1 week" > > > SetHandler application/x-httpd-php > Header set Content-Type "application/xml" > ExpiresDefault "access plus 1 year" > > > tested on Apache 2.4.X builds. > > How to fix this issue? > > > > Binyamin >
Re: [users@httpd] Why ExpiresByType is ignored when has SetHandler application/x-httpd-php ?
בע"ה Hi, As I wrote in earlier example, `Header set Content-Type "application/xml"` still returns 1 day expiration (not the one defined in ExpiresByType). The same result when switching configuration order of FilesMatch before ExpiresDefault, or order of LoadModule's expires_module and headers_module. Also this example will return expiration only 1 day, while expected 1 year: Header set Content-Type "application/xml" ExpiresDefault "access plus 1 year" it returns Content-Type: application/xml Date: Wed, 28 Dec 2016 06:38:09 GMT Expires: Thu, 29 Dec 2016 06:38:09 GMT It seems to as a Apache bug. I don't know if ever it was working. Any workaround (configuration fix) for it for now? Do you know if it worked right in any Apache build/version? Binyamin On Wed, Dec 28, 2016 at 5:29 AM, Yehuda Katz wrote: > It might have something to do with the order the modules handle the > request. > What happens if you tell PHP to set the content type to application/xml? > > - Y > > On Tue, Dec 27, 2016 at 3:55 PM, Binyamin <7rai...@inbox.lv> wrote: > >> בע"ה >> >> >> Why ExpiresByType is ignored when has SetHandler application/x-httpd-php ? >> >> /sitemap.xml Response Headers shows 1 day expiration while expected to be >> 1 year (1 month) >> >> Content-Type: application/xml; charset=utf-8 >> Date: Tue, 27 Dec 2016 19:59:00 GMT >> Expires: Wed, 28 Dec 2016 19:59:00 GMT >> >> seems SetHandler forces it to apply text/html expiration and doesn't >> allow to rewrite it >> >> ExpiresActive On >> ExpiresDefault"access plus 1 month" >> ExpiresByType text/html "access plus 1 day" >> ExpiresByType application/xml "access plus 1 week" >> >> >> SetHandler application/x-httpd-php >> Header set Content-Type "application/xml" >> ExpiresDefault "access plus 1 year" >> >> >> tested on Apache 2.4.X builds. >> >> How to fix this issue? >> >> >> >> Binyamin >> > >
Re: [users@httpd] Why ExpiresByType is ignored when has SetHandler application/x-httpd-php ?
Hi, I regularly use php to generate all kinds of different XML.
This is what I do -
header('Content-Type: application/xml');
print($dom->saveXML());
exit();
Of course in that case $dom is a DOMDocument object - if you are using
print or echo to create XML then you need the header at the beginning of
the php, as it needs to be before any content is sent.
Using php to send the header avoids the need to set it with Apache.
On 12/27/2016 10:58 PM, Binyamin wrote:
בע"ה
Hi,
As I wrote in earlier example, `Header set Content-Type
"application/xml"` still returns 1 day expiration (not the one defined
in ExpiresByType).
The same result when switching configuration order of FilesMatch
before ExpiresDefault, or order of LoadModule's expires_module and
headers_module.
Also this example will return expiration only 1 day, while expected 1 year:
Header set Content-Type "application/xml"
ExpiresDefault "access plus 1 year"
it returns
Content-Type: application/xml
Date: Wed, 28 Dec 2016 06:38:09 GMT
Expires: Thu, 29 Dec 2016 06:38:09 GMT
It seems to as a Apache bug. I don't know if ever it was working.
Any workaround (configuration fix) for it for now?
Do you know if it worked right in any Apache build/version?
Binyamin
On Wed, Dec 28, 2016 at 5:29 AM, Yehuda Katz mailto:yeh...@ymkatz.net>> wrote:
It might have something to do with the order the modules handle the
request.
What happens if you tell PHP to set the content type to application/xml?
- Y
On Tue, Dec 27, 2016 at 3:55 PM, Binyamin <7rai...@inbox.lv
> wrote:
בע"ה
Why ExpiresByType is ignored when has SetHandler
application/x-httpd-php ?
/sitemap.xml Response Headers shows 1 day expiration while
expected to be 1 year (1 month)
Content-Type: application/xml; charset=utf-8
Date: Tue, 27 Dec 2016 19:59:00 GMT
Expires: Wed, 28 Dec 2016 19:59:00 GMT
seems SetHandler forces it to apply text/html expiration and
doesn't allow to rewrite it
ExpiresActive On
ExpiresDefault"access plus 1 month"
ExpiresByType text/html "access plus 1 day"
ExpiresByType application/xml "access plus 1 week"
SetHandler application/x-httpd-php
Header set Content-Type "application/xml"
ExpiresDefault "access plus 1 year"
tested on Apache 2.4.X builds.
How to fix this issue?
Binyamin
-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
Re: [users@httpd] Why ExpiresByType is ignored when has SetHandler application/x-httpd-php ?
Oh I should add - when it is a php file I also set the cache control via
php.
header('Cache-Control: max-age=' . $maxage);
for example.
On 12/27/2016 11:12 PM, Michael A. Peters wrote:
Hi, I regularly use php to generate all kinds of different XML.
This is what I do -
header('Content-Type: application/xml');
print($dom->saveXML());
exit();
Of course in that case $dom is a DOMDocument object - if you are using
print or echo to create XML then you need the header at the beginning of
the php, as it needs to be before any content is sent.
Using php to send the header avoids the need to set it with Apache.
On 12/27/2016 10:58 PM, Binyamin wrote:
בע"ה
Hi,
As I wrote in earlier example, `Header set Content-Type
"application/xml"` still returns 1 day expiration (not the one defined
in ExpiresByType).
The same result when switching configuration order of FilesMatch
before ExpiresDefault, or order of LoadModule's expires_module and
headers_module.
Also this example will return expiration only 1 day, while expected 1
year:
Header set Content-Type "application/xml"
ExpiresDefault "access plus 1 year"
it returns
Content-Type: application/xml
Date: Wed, 28 Dec 2016 06:38:09 GMT
Expires: Thu, 29 Dec 2016 06:38:09 GMT
It seems to as a Apache bug. I don't know if ever it was working.
Any workaround (configuration fix) for it for now?
Do you know if it worked right in any Apache build/version?
Binyamin
On Wed, Dec 28, 2016 at 5:29 AM, Yehuda Katz mailto:yeh...@ymkatz.net>> wrote:
It might have something to do with the order the modules handle the
request.
What happens if you tell PHP to set the content type to
application/xml?
- Y
On Tue, Dec 27, 2016 at 3:55 PM, Binyamin <7rai...@inbox.lv
> wrote:
בע"ה
Why ExpiresByType is ignored when has SetHandler
application/x-httpd-php ?
/sitemap.xml Response Headers shows 1 day expiration while
expected to be 1 year (1 month)
Content-Type: application/xml; charset=utf-8
Date: Tue, 27 Dec 2016 19:59:00 GMT
Expires: Wed, 28 Dec 2016 19:59:00 GMT
seems SetHandler forces it to apply text/html expiration and
doesn't allow to rewrite it
ExpiresActive On
ExpiresDefault"access plus 1 month"
ExpiresByType text/html "access plus 1 day"
ExpiresByType application/xml "access plus 1 week"
SetHandler application/x-httpd-php
Header set Content-Type "application/xml"
ExpiresDefault "access plus 1 year"
tested on Apache 2.4.X builds.
How to fix this issue?
Binyamin
-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
