[users@httpd] Announcing mod_websocket v0.1.2

[Jacob Champion]

I'm happy to announce version 0.1.2 of mod_websocket:

https://github.com/jchampio/apache-websocket/releases/tag/0.1.2

mod_websocket is an Apache 2.x module that allows developers to write C-
and C++-based WebSocket services. The intent is for mod_websocket plugin
writers to develop their services independently of the Apache server API.

This is a "dust off the build" release -- the user-facing changes have
been in master for four years, but never officially released. One major
bug has been fixed, a few minor cleanups have been made, and a new build
system for *nix platforms was contributed to the project. I am also
dropping testing coverage for the obsolete 2.2 server line, though I
won't intentionally break 2.2 features until a future 0.2 release.

= Major New Features/Fixes =

- Extremely fragmented messages no longer cause poor performance and
  possible DoS conditions. Thanks to Paul Spangler for his fix
  suggestion!
- The CMake build system now supports *nix platforms as well as Windows.
  Thanks to @toniotelli for the contribution!
- The 'MaxMessageSize' directive has been renamed to
  'WebSocketMaxMessageSize'; its previous spelling is deprecated and
  will be removed in the future.

A full changelist can be seen at the release description on GitHub.

= Major Known Issues =

This is a pre-release, zero-dot module. There are known issues that may
preclude its use in production systems. Please understand them and take
steps to avoid them if you decide to deploy mod_websocket.

- Apache worker threads are completely monopolized by WebSocket
  connections. This makes it possible for a large number of connections
  to DoS the server.

A more complete (but not necessarily exhaustive) list is available at
the repo page on GitHub:

https://github.com/jchampio/apache-websocket/issues

= What's Next =

There's a lot of stuff to do. During my absence from the project,
WebSocket has received a transport based on HTTP/2, several optional
WebSocket features have seen more mainstream use, and Python 2 was
EoL'd. And the existing issues list didn't become any shorter,
unfortunately.

Questions? Comments? Let me know. Thanks for your interest!

--Jacob Champion

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] WebSockets support in transparent proxy

[Jacob Champion]

On 07/18/2017 12:24 PM, Ray Navarette wrote:
I can reproduce similar behavior using the websocket echo test 
(http://www.websocket.org/echo.html).  When this site is accessed 
through the proxy server, unsecured (again, initiated as http) 
websocket connections fail.  Interestingly, this demo also supports 
secured websocket connection and when selecting this option, the

demo works fine.  Seems that the https traffic is forwarded in a way
that the websockets still work successfully.


Assuming this is really a forward proxy use case (and based on your
description, I'm still a little confused):

HTTP upgrade is hop-by-hop. To get a WebSocket connection through a
(forward) proxy for a ws:// URL, you need to CONNECT through the proxy
to set up an end-to-end connection. How you configure this is probably
client-specific.

wss:// URLs "just work" because the TLS connection is end-to-end.
This is one of the reasons that the use of wss:// is encouraged over ws://.

--Jacob

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Apache (2.4.26) changing permissions on passwd file?

[Jacob Champion]

On 07/11/2017 09:12 AM, Alexandru Duzsardi wrote:
how does the httpd process change the permissions of that file? does 
that before droping root privileges? if not what would it stop it to 
change any file permissions?


OP said htpasswd was touching the file, not httpd.

--Jacob

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Apache (2.4.26) changing permissions on passwd file?

[Jacob Champion]

On 07/11/2017 08:53 AM, Kevin Miles wrote:
Sure enough, when I check /etc/stm/passwd its permissions have been 
changed from 644 to 600. When I change them back, everything starts 
working. But when I reload the system, something sets them back to 600 
and it stops working!


This looks like PR61240 [1], which should be fixed in the just-announced 
2.4.27.


--Jacob

[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=61240

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] ownCloud / PHP-FPM problem after upgrade to 2.4.26

[Jacob Champion]

On 06/27/2017 01:42 PM, rockzOr wrote:

Is there a plan for releasing 2.4.27 as for the broken behaviour or
will it be next regular release in X months?


Bill had a good answer in another thread [1]:

On 06/27/2017 10:15 AM, William A Rowe Jr wrote:

We don't generally try to predict our release schedule, when it's
baked we publish a release.

But Jim and Jacob are furiously updating the test framework as you
were asking your question, so I'm guessing the group will be working
to release this fix just as soon as it is agreed upon, within a week
or few.


--Jacob

[1] 
https://lists.apache.org/thread.html/e7c63db48d314c55b33cf5185166ed97fc2a8b797159072ecbeaf9d7@%3Cdev.httpd.apache.org%3E


-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] ownCloud / PHP-FPM problem after upgrade to 2.4.26

[Jacob Champion]

On 06/27/2017 12:48 PM, rockzOr wrote:

Hi all,

I've got a problem after upgrading to 2.4.26. Everything works fine 
except my ownCloud instance.


Fair warning: I haven't looked through all of the info you provided (but 
thank you for being thorough!). FPM problems after upgrading to 2.4.26 
are almost certainly due to bug 61202 [1], which we are working on now.


You can verify that this is your problem by adding "proxy_fcgi:trace8" 
to your LogLevel, finding the log entry that says "AH01062: sending env 
var 'SCRIPT_NAME'", and comparing the value of SCRIPT_NAME we now send 
in 2.4.26 to the one that we sent in 2.4.25. If they're different -- 
typically the 2.4.26 value is left-truncated -- then this is most likely 
your bug.


If you need a quick fix, and you know 2.4.25 worked for you, you can 
return to the 2.4.25 behavior by using the directive 
"ProxyFCGIBackendType GENERIC". This isn't a viable fix for everyone, 
because it breaks other FPM configurations that used to work prior to 
2.4.21. We're working on reverting to the 2.4.20 behavior by default and 
filling out the test suite so we don't break you again.


I'm sorry for the inconvenience, and thanks for your patience.

--Jacob

[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=61202

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] if directive not being respected in Apache 2.4.6

[Jacob Champion]

On 06/21/2017 08:45 AM, William A Rowe Jr wrote:

Frankly I'd think scope should be defined as Global only,
even though it won't error out in these other cases. For
trunk, it would be good to lock this down and eliminate
the legacy 'support' of Define in sections.


+1.

Very long-term, I think it would be good for all EXEC_ON_READ directives 
to be distinguished by the config syntax itself. Similar to #include and 
#define in C. I've been tinkering around with that a little in my spare 
cycles.


--Jacob

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

[users@httpd] CVE-2017-7679: mod_mime buffer overread

[Jacob Champion]

CVE-2017-7679: mod_mime buffer overread

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
httpd 2.2.0 to 2.2.32
httpd 2.4.0 to 2.4.25

Description:
mod_mime can read one byte past the end of a buffer when sending a
malicious Content-Type response header.

Mitigation:
2.2.x users should either apply the patch available at
https://www.apache.org/dist/httpd/patches/apply_to_2.2.32/CVE-2017-7679.patch
or upgrade in the future to 2.2.33, which is currently unreleased.

2.4.x users should upgrade to 2.4.26.

Credit:
The Apache HTTP Server security team would like to thank ChenQin and
Hanno Böck for reporting this issue.

References:
https://httpd.apache.org/security_report.html

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

[users@httpd] CVE-2017-3169: mod_ssl null pointer dereference

[Jacob Champion]

CVE-2017-3169: mod_ssl null pointer dereference

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
httpd 2.2.0 to 2.2.32
httpd 2.4.0 to 2.4.25

Description:
mod_ssl may dereference a NULL pointer when third-party modules call
ap_hook_process_connection() during an HTTP request to an HTTPS port.

Mitigation:
2.2.x users should either apply the patch available at
https://www.apache.org/dist/httpd/patches/apply_to_2.2.32/CVE-2017-3169.patch
or upgrade in the future to 2.2.33, which is currently unreleased.

2.4.x users should upgrade to 2.4.26.

Credit:
The Apache HTTP Server security team would like to thank Vasileios
Panopoulos and AdNovum Informatik AG for reporting this issue.

References:
https://httpd.apache.org/security_report.html

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

[users@httpd] CVE-2017-7668: ap_find_token buffer overread

[Jacob Champion]

CVE-2017-7668: ap_find_token buffer overread

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
httpd 2.2.32
httpd 2.4.24 (unreleased)
httpd 2.4.25

Description:
The HTTP strict parsing changes added in 2.2.32 and 2.4.24 introduced a
bug in token list parsing, which allows ap_find_token() to search past
the end of its input string. By maliciously crafting a sequence of
request headers, an attacker may be able to cause a segmentation fault,
or to force ap_find_token() to return an incorrect value.

Mitigation:
2.2.32 users should either apply the patch available at
https://www.apache.org/dist/httpd/patches/apply_to_2.2.32/CVE-2017-7668.patch
or upgrade in the future to 2.2.33, which is currently unreleased.

2.4.25 users should upgrade to 2.4.26.

Credit:
The Apache HTTP Server security team would like to thank Javier Jiménez
(javij...@gmail.com) for reporting this issue.

References:
https://httpd.apache.org/security_report.html

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

[users@httpd] CVE-2017-3167: ap_get_basic_auth_pw authentication bypass

[Jacob Champion]

CVE-2017-3167: ap_get_basic_auth_pw authentication bypass

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
httpd 2.2.0 to 2.2.32
httpd 2.4.0 to 2.4.25

Description:
Use of the ap_get_basic_auth_pw() by third-party modules outside of the
authentication phase may lead to authentication requirements being
bypassed.

Mitigation:
2.2.x users should either apply the patch available at
https://www.apache.org/dist/httpd/patches/apply_to_2.2.32/CVE-2017-3167.patch
or upgrade in the future to 2.2.33, which is currently unreleased.

2.4.x users should upgrade to 2.4.26.

Third-party module writers SHOULD use ap_get_basic_auth_components(),
available in 2.2.33 and 2.4.26, instead of ap_get_basic_auth_pw().
Modules which call the legacy ap_get_basic_auth_pw() during the
authentication phase MUST either immediately authenticate the user after
the call, or else stop the request immediately with an error response,
to avoid incorrectly authenticating the current request.

Credit:
The Apache HTTP Server security team would like to thank Emmanuel
Dreyfus for reporting this issue.

References:
https://httpd.apache.org/security_report.html

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] HTTPOxy vulnerability not posted to announce list?

[Jacob Champion]

On 12/21/2016 11:20 AM, Jim Allison wrote:

Going through the history of the announce list, it seems that the advisory for 
HTTPOxy was not posted there. I can see that it was posted to the users list 
back in the summer, but we were only subscribed to the announce list. I can see 
that other vulnerabilities were posted to the announce list last year; just not 
HTTPOxy.


Just a guess -- it may have been to avoid confusion, since HTTPoxy is a 
vulnerability in the CGI backends, not the server itself. (But it's 
simple to *mitigate* that vulnerability directly in the server, which is 
why a patch was released.)


--Jacob

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Conditionally LoadModule?

[Jacob Champion]

On 11/15/2016 09:19 AM, Nick Kew wrote:

So IfFile joins IfDefine and the infamous[1] IfModule.  What next?
We can't get rid of them in the lifetime of 2.4, but maybe thereafter
they could come together?


Is there a way we could provide a "startup-time" subset of ap_exprs?


[1] because it gives rise to so much confusion amongst users.


Is that because of a problem in  itself, or just in its 
overuse? (E.g., on IRC we tend to complain about it, not because it's 
confusing, but because it has achieved cargo-cult status: people use it 
everywhere whether they need it or not, and it silently covers up their 
failure to load modules they need, which is exactly as designed.)


Also, tangential but related: it would be very nice if, for a 2.next or 
3.0, we explicitly separated directives that ran at different times by 
their syntax.  are like C preprocessor directives, in 
that they affect what the server sees in the configuration.  is a 
request-time conditional. They should really not look so similar.


--Jacob

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Apache 2.4.12+ on Windows x64 stops responding to requests

[Jacob Champion]

On 08/09/2016 07:22 AM, Paul Spangler wrote:

Though in our case, we only needed to use

AcceptFilter http connect
AcceptFilter https connect

rather than turning it off completely using "none". Setting it to
connect allows the server to recycle sockets.

I'll see if I can't look back into it and try to find a reproduction
case again that I can narrow down.


Thanks Paul!

At this point, my primary suspect is our use of recycled OVERLAPPED 
structs without reinitializing them to zero. To make matters worse, 
we're setting the OVERLAPPED's internal .Pointer field in the 
AcceptFilter 'data' case -- which we're not supposed to be doing to 
begin with [1]. We don't do that in the 'connect' filter.


This is all just theorycrafting, though. I'll try to reproduce on my end 
too.


--Jacob

[1] 
https://msdn.microsoft.com/en-us/library/windows/desktop/ms684342(v=vs.85).aspx 
(the Members > Pointer section)


-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Apache 2.4.12+ on Windows x64 stops responding to requests

[Jacob Champion]

On 07/25/2016 11:13 AM, Arthur Ramsey wrote:

I think I will try the following settings first, but failing that I'll
give the x86 build a try.

AcceptFilter https none


Any follow-up on this? I've been digging into the AcceptEx() 
implementation, since it looks like there have been intermittent 
problems with it for a while now. If you have a reproduction case, I'd 
be happy to run with it.


--Jacob

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

[users@httpd] Announcing mod_websocket v0.1.1

[Jacob Champion]

I'm happy to announce version 0.1.1 of mod_websocket:

https://github.com/jchampio/apache-websocket/releases/tag/0.1.1

This is a bugfix release that also adds major improvements to the build 
and test process.


mod_websocket is an Apache 2.x module that allows developers to write C-
and C++-based WebSocket services. The intent is for mod_websocket plugin
writers to develop their services independently of the Apache server API.

= Major New Features/Fixes =

- WebSocket connections are no longer closed prematurely by
  mod_reqtimeout. (Thanks to Eric Covener for his help with this fix!)
- The MaxMessageSize directive now correctly applies to full messages
  instead of individual frames.
- GNU Autoconf support has been added (and the included test suite is
  much easier to run).
- Several Autobahn|TestSuite issues have been fixed; the test suite now
  passes at 100%.

A full changelist can be seen at the release description on GitHub.

= Major Known Issues =

This is a pre-release, zero-dot module. There are known issues that may
preclude its use in production systems. Please understand them and take
steps to avoid them if you decide to deploy mod_websocket.

- Apache worker threads are completely monopolized by WebSocket
  connections. This makes it possible for a large number of connections
  to DoS the server.
- mod_websocket suffers from poor performance when receiving extremely
  fragmented messages (i.e. a large number of small frames). In an
  untrusted environment, this could also lead to a denial of service
  condition.

A more complete (but not necessarily exhaustive) list is available at
the repo page on GitHub:

https://github.com/jchampio/apache-websocket/issues

= Questions? Comments? =

If you have any feedback on the plugin API (or any other part of the
project), now is an excellent time to let me know. Follow or fork the
project on GitHub, file issues, open pull requests! And as always,
thanks for your interest.

--Jacob Champion

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Temporarily authentication errors with auth_dbd and postgres

[Jacob Champion]

On Dec 18, 2015 6:23 AM, "Klaus Darilion" 
wrote:
>
> For the records: Since we use Apache 2.4.17 we do not have that problem
> anymore.

Excellent! Glad that seems to have solved it. Thanks for reporting back.

--Jacob
[on mobile; sorry for any formatting annoyances]

Re: [users@httpd] explicitly including other ciphers for use with https

[Jacob Champion]

On 12/07/2015 09:54 PM, William A Rowe Jr wrote:

On Dec 7, 2015 11:36 PM, "Marat Khalili" > wrote:
 >>
 >> Everything *after* that handshake, in cleartext, is open for
inspection or for manipulation
 >
 > Are you sure about the manipulation part? Why do you think encryption
helps here then?

To turn the question around, what gives you the suggestion that the user
agent or the httpd server would notice any modification of plaintext
bytes in transit through a router or other network intermediate?


I would _expect_ that clients using an eNULL ciphersuite would check the 
MAC that is transferred as part of the TLS record. I would further 
expect the MAC to have been computed using a secret that was set up 
during the initial handshake, so that it cannot be faked by an 
intermediary who has been watching the stream. That's what I meant when 
I said that NULL encryption should have (AFAIK) no effect on the authn 
and integrity characteristics of the ciphersuites. It should only affect 
the confidentiality.


But I'm not an expert in TLS -- do you know of a reason that eNULL 
ciphersuites have weaker guarantees on their integrity checks? If so, 
I'd really like to know... This is the second time in a week that 
someone has told me that eNULL ciphers provide effectively no security, 
and up to this point I have believed otherwise.


(As an experiment, I compiled httpd to allow eNULL ciphersuites and 
captured an s_client conversation with dumpcap. Wireshark immediately 
"decrypted" the plaintext data but showed that there was still a MAC 
appended to each record. Modifying a single byte of that data caused 
Wireshark to fail its "decryption" of that record.)


--Jacob

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] explicitly including other ciphers for use with https

[Jacob Champion]

On 12/07/2015 05:06 PM, William A Rowe Jr wrote:

On Mon, Dec 7, 2015 at 2:39 PM, Ron Croonenberg > wrote:

Hello,

I a building a storage system, using HTTP/HTTPS for ingesting data.

I would like to use the authentication over HTTPS, while after that
I want no encryption on the data because of peformance.


Then you probably don't understand the performance impact of TLS.


To help Ron out a little... he's coming from this conversation [1] on 
the openssl-users mailing list, where he's described his rather unusual 
network topology already.


I'm still unsure as to whether or not his proposed solution is secure... 
but I am convinced that his use case is atypical.



Otherwise,
any man-in-the-middle can observe the data in transit and alter
the data passed between your client and backend storage server


Wait, why does the use of NULL encryption have any effect on the 
authenticity/integrity characteristics of the cipher? I asserted 
otherwise on openssl-users and was not corrected...


--Jacob

[1] https://marc.info/?t=14490098273=1=2

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Temporarily authentication errors with auth_dbd and postgres

[Jacob Champion]

On 02.12.2015 23:05, Nick Kew wrote:

On Wed, 2 Dec 2015 22:11:20 +0100
Klaus Darilion  wrote:


[ ...]


A puzzle indeed.


Although the DB returns the same password-hash as always, and the
browser sends the correct credentials (as in the working scenario),
Apache replies with 401.


Klaus,

You should try Nick's suggestions for debugging (varying the parameters) 
first. But just in case: I recall that a handful of memory allocation 
bugs in authn_dbd (and related code) were fixed earlier this year.


My experience was with SQLite, not PostgreSQL, but we also saw 
nondeterministic authn failures that went away after we cherry-picked 
several patches from the latest httpd version. If you have the means to 
update versions easily (or if you just get desperate enough), you might 
check to see if that fixes your problem.


Good luck,
--Jacob

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Announcing mod_websocket v0.1.0

[Jacob Champion]

On 11/12/2015 06:39 AM, Rich Bowen wrote:

On 11/10/2015 03:33 PM, Jacob Champion wrote:

I'm happy to announce version 0.1.0 of mod_websocket:

https://github.com/jchampio/apache-websocket/releases/tag/0.1.0


Jacob,

First, congratulations on your release.


Hi Rich, thanks very much!


Next, I'd encourage you to take the discussion to the dev@ list, where
other httpd module developers may be interested in participating in
the effort, and may have a deeper understanding of what you're trying
to accomplish. Granted, many/most of those folks are also subscribed
here, but tend not to watch this list very closely.


I cross-posted to modules-dev@, since I wasn't sure if a third-party 
module was actually on topic for dev@. If you still think dev@ would be 
more appropriate, I can drop a note there as well.


Thanks for the feedback,
--Jacob

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

[users@httpd] Announcing mod_websocket v0.1.0

[Jacob Champion]

I'm happy to announce version 0.1.0 of mod_websocket:

https://github.com/jchampio/apache-websocket/releases/tag/0.1.0

mod_websocket is an Apache 2.x module that allows developers to write C-
and C++-based WebSocket services. The intent is for mod_websocket-plugin
writers to develop their WebSocket services completely independently of
the Apache server API. Currently, both httpd 2.2 and 2.4 are supported.

I am not the original author of mod_websocket; it's been orphaned for a
couple of years now, and I'm stepping in as a new primary maintainer. So
if you're interested in the development or use of this module, now is an
excellent time to get involved! Download and test the code, file issues
(or try your hand at fixing one), star/fork the repo on GitHub, etc. Any
and all feedback is appreciated.

= Major New Features/Fixes =

Since the last upstream commit in 2012, here are some of the major
changes in 0.1.0:

- Incoming handshakes are now validated and rejected if they do not
  conform to the WebSocket specification. This is the primary focus of
  the 0.1.0 release.
- Cross-origin connections are now rejected by default, and a new
  WebSocketOriginCheck directive has been added to control this
  behavior.
- A major rearchitecture of the threading model fixes occasional crashes
  when using mod_ssl.
- Experimental CMake support has been added for Windows builds.
- An autotest harness has been added, which uses the Autobahn TestSuite.

A full changelist can be seen at the release description on GitHub.

= Major Known Issues =

This is a pre-release, zero-dot module. There are known issues that may
preclude its use in production systems. Please understand them and take
steps to avoid them if you decide to deploy mod_websocket.

- mod_reqtimeout will prematurely close idle WebSocket connections if it
  is in use.
- Apache worker threads are completely monopolized by WebSocket
  connections. This makes it possible for a large number of connections
  to DoS the server.
- mod_websocket suffers from poor performance when receiving extremely
  fragmented messages (i.e. a large number of small frames). In an
  untrusted environment, this could also lead to a denial of service
  condition.

A more complete (but not necessarily exhaustive) list is available at
the repo page on GitHub:

https://github.com/jchampio/apache-websocket/issues

= Binary Compatibility =

The plugin ABI is *not* yet stable, but the 0.1.x line is
binary-compatible with the original upstream fork. So if you already
have mod_websocket plugins based on the original repository, no changes
should be required for you to use them with this release. There *will*
eventually be an ABI bump (0.2.x) to fix some known issues with the
interfaces, but I'll do my best to consolidate those compatibility
breaks and drive towards a 1.0 as soon as possible.

Thanks for your interest!

--Jacob Champion

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Re: make apache 2.4.17 portable under ubuntu

[Jacob Champion]

On 10/16/2015 06:23 PM, Good Guy wrote:

I got it from the Master in this video:



Just after 6 minutes in the video he is talking about binaries and all
that.


When Linus says "you don't make binaries for Linux", he means that 
maintaining and shipping prebuilt binaries for Linux distributions is 
typically unfeasible, for a huge number of reasons. He doesn't mean that 
Linux systems don't use binaries, because they do.


--Jacob


-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org