state of mod_spdy ?
Hello, I wanted to try spdy on my webservers. It seems currently the situation is a bit confusing. There's the original google location of mod_spdy but it says its basically deprecated and the code has been moved to apache's svn. https://code.google.com/p/mod-spdy/ Here's apache's repo: https://svn.apache.org/viewvc/httpd/mod_spdy/trunk/ It seems its not very active. And it doesn't even have any build instructions. I tried applying the google-code-build-instructions to it, but failed. There seems to be no straightforward way to use this. Then there seems to be an inofficial git repo: https://github.com/eousphoros/mod-spdy It builds and I can load and enable it, but it doesn't work (can't connect any more to https sites when I enable it). So what's the reference place of spdy support for apache? Is there any active development happening right now? cu, -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 signature.asc Description: PGP signature
Re: Coding standards, avoiding vulnerabilities in httpd
On Tue, Sep 16, 2014 at 9:09 PM, Notes Jonny jong...@gmail.com wrote: Hello I had a quick look at httpd 2.4.10 (couldn't find on the website how to site how to checkout the trunk) http://httpd.apache.org/docs/trunk/ Taking this file as an example: httpd-2.4.10/modules/ssl/ssl_engine_init.c 1) Doesn't check make_dh_params() prime is a non-NULL valid function pointer. 2) DH *modssl_get_dh_params(unsigned keylen). keylen doesn't have a type. better to write unsigned int keylen 3) ssl_add_version_components() doesn't check s and p are valid non-NULL parameters before using them. 4) ssl_add_version_components() modver incver libver should probably be const char * 5) ssl_init_Module() all pointer params should be checked to be non-NULL, and an appropriate error apr_status_t returned (something other than APR_SUCCESS) In my view, worth making these changes. You may already be familiar with ISO/IEC TR 24772 which covers these kind of things. Regards, Jonny Hello Would a patch be supported to add these improvements?
Re: state of mod_spdy ?
On Tue, Oct 21, 2014 at 8:15 AM, Hanno Böck ha...@hboeck.de wrote: So what's the reference place of spdy support for apache? Is there any active development happening right now? From all indications I see, it doesn't appear to be actively used or developed post-donation of the code to Apache. It also hasn't been part of any httpd release.
Re: state of mod_spdy ?
On Tue, 21 Oct 2014 14:15:46 +0200 Hanno Böck ha...@hboeck.de wrote: So what's the reference place of spdy support for apache? Is there any active development happening right now? It needs a community of people willingable to work on it. And motivated! If you have the capability, try installing the current code and see how it works for you. Your feedback could help stimulate such a community. If you're a programmer then actual patches, otherwise reports of what does or doesn't work well, bugs, feature requests. -- Nick Kew
Re: MAJOR SECURITY-PROBLEM Apache 2.4.6
On Wed, Oct 1, 2014 at 2:19 PM, Eric Covener cove...@gmail.com wrote: On Wed, Oct 1, 2014 at 2:16 PM, Eric Covener cove...@gmail.com wrote: To me, this does not exonerate mod_php, it implicates it. I suspect your source code is served because PHP swallowed the LimitRequestBody and then passed control back to Apache. I'm fairly certain I responded to you privately with similar information already. I should add that I don't understand your scenario completely, where the file is not processed. I think my own test result was the same as Yehuda ITT which is not the same as what I just described with the default handler taking over. 1. Is this result (PHP executed) still a bug (could be in mod_php)? If a 413 comes up, shouldn't no other content be returned? I am considering setting up a new VM to do some testing, but I want to make sure this is not the expected behavior (whether the PHP is executed or not). 2. Is there another module that hooks in with a similar way to mod_php that might also show this behavior (mod_lua for example)? - Y
Re: MAJOR SECURITY-PROBLEM Apache 2.4.6
On 22 October 2014 13:51, Yehuda Katz yeh...@ymkatz.net wrote:
On Wed, Oct 1, 2014 at 2:19 PM, Eric Covener cove...@gmail.com wrote:
On Wed, Oct 1, 2014 at 2:16 PM, Eric Covener cove...@gmail.com wrote:
To me, this does not exonerate mod_php, it implicates it. I suspect
your source code is served because PHP swallowed the LimitRequestBody and
then passed control back to Apache. I'm fairly certain I responded to you
privately with similar information already.
I should add that I don't understand your scenario completely, where the
file is not processed. I think my own test result was the same as Yehuda
ITT which is not the same as what I just described with the default handler
taking over.
1. Is this result (PHP executed) still a bug (could be in mod_php)? If a
413 comes up, shouldn't no other content be returned?
I am considering setting up a new VM to do some testing, but I want to
make sure this is not the expected behavior (whether the PHP is executed or
not).
2. Is there another module that hooks in with a similar way to mod_php
that might also show this behavior (mod_lua for example)?
FWIW, I noted similar behaviour in implementing mod_wsgi many years ago.
Since then I have code in mod_wsgi in the handler before anything is done
which specifically does:
/*
* Check to see if the request content is too large if the
* Content-Length header is defined then end the request here. We do
* this as otherwise it will not be done until first time input data
* is read in by the application. Problem is that underlying HTTP
* output filter will also generate a 413 response and the error
* raised from the application will be appended to that. The call to
* ap_discard_request_body() is hopefully enough to trigger sending
* of the 413 response by the HTTP filter.
*/
lenp = apr_table_get(r-headers_in, Content-Length);
if (lenp) {
char *endstr;
apr_off_t length;
if (wsgi_strtoff(length, lenp, endstr, 10)
|| *endstr || length 0) {
wsgi_log_script_error(r, apr_psprintf(r-pool,
Invalid Content-Length header value of '%s' was
supplied., lenp), r-filename);
return HTTP_BAD_REQUEST;
}
limit = ap_get_limit_req_body(r);
if (limit limit length) {
ap_discard_request_body(r);
return OK;
}
}
So in the case of mod_wsgi it wasn't that the source code was being
appended, but that any error response from the hosted Python WSGI
application, generated in reaction to the reading of the request content
failing because of the length check by the input filter, that got appended
to the end of the 413 error response that the HTTP filter had already
caused to be delivered back.
Graham
