Re: How to write apache module in C through which to retrieve POST form data from browser?
You can take a look at a small module I wrote for myself https://github.com/danghvu/mod_dumpost p/s: I did submit it for review but apparently this list is not so active. On Jan 5, 2013, at 7:13 PM, Dhiren123 dhiren42.sili...@gmail.com wrote: I am already written a apache module in c and parsed GET data from browser through r-args .But donot know how i retrieve the POST form data ,Anybody suggest me.. -- View this message in context: http://apache-http-server.18135.n6.nabble.com/How-to-write-apache-module-in-C-through-which-to-retrieve-POST-form-data-from-browser-tp5002469.html Sent from the Apache HTTP Server - Module Writers mailing list archive at Nabble.com.
Re: How to write apache module in C through which to retrieve POST form data from browser?
Take a look at mod_apreq http://httpd.apache.org/apreq/docs/libapreq2/ On 05/01/2013 20:13, Dhiren123 wrote: I am already written a apache module in c and parsed GET data from browser through r-args .But donot know how i retrieve the POST form data ,Anybody suggest me.. -- View this message in context: http://apache-http-server.18135.n6.nabble.com/How-to-write-apache-module-in-C-through-which-to-retrieve-POST-form-data-from-browser-tp5002469.html Sent from the Apache HTTP Server - Module Writers mailing list archive at Nabble.com.
Re: [VOTE] accept mod_macro as standard module in httpd
+1 - Original Message - I was preparing the IP clearance forms and noticed our original vote thread was more of a discussion. I wanted to record a formal vote here so I can link to it. Pending IP clearance... [+1] accept mod_macro as a standard module and responsibility for its maintenance [ +/- 0] don't care won't help [ -1] don't accept mod_macro as a standard module My +1 -- Eric Covener cove...@gmail.com -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: [users@httpd] SSL, SNI and SSLStrictSNIVHostCheck
Thomas,
I think the users@ list may be the wrong target for such discussion.
FWDing to dev@
- Original Message -
Is the directive
SSLStrictSNIVHostCheck On
meant to block connections to a virtual host if the connecting
client
uses an IP literal as URL ? RFC 6066 states that
Literal IPv4 and IPv6 addresses are not permitted in HostName.
since a SNI doesn't make sense at all for an IP literal and this
(https://bugzilla.mozilla.org/show_bug.cgi?id=421634) bug
report/patch
for FF does exactly what I would expect for such a client request,
which
is to not send any SNI at all.
The docs don't mention this corner case
(http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslstrictsnivhostcheck)
and I think the issue traces to
httpd-2.4.3/modules/ssl/ssl_engine_kernel.c:166
where there is no check if the SNI is necessary at all, only it if
present:
if ((servername = SSL_get_servername(ssl,
TLSEXT_NAMETYPE_host_name))) {
So if this is not working as intended I suggest adding an IP literal
detection at this place and if it is working as intended I would like
to
know the reasoning behind it.
Cheers,
Thomas
-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.ga...@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: [VOTE] accept mod_macro as standard module in httpd
+1 it's awesome! MATSUMOTO Ryosuke matsu1229 at gmail.com http://blog.matsumoto-r.jp/ On 2013/01/05, at 18:30, Igor Galić i.ga...@brainsware.org wrote: +1 - Original Message - I was preparing the IP clearance forms and noticed our original vote thread was more of a discussion. I wanted to record a formal vote here so I can link to it. Pending IP clearance... [+1] accept mod_macro as a standard module and responsibility for its maintenance [ +/- 0] don't care won't help [ -1] don't accept mod_macro as a standard module My +1 -- Eric Covener cove...@gmail.com -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: [Discuss] mod_lua and database connectivity
Implied semantics matter a LOT in API design. +1 Check your errors :-) I don't need to check errors, I just need to check whether 'rows' is a table or a nil value in the case of an error. I could've checked if 'err' was anything, but the result is the same. An API which returns (foo, err) should be error checked on the error, not the foo. This style of API will sometimes return a foo in a bad state, and an err to let you know. In your example this is fine, I am just being a pedant because if an API is designed a certain way, we should use it that way :-) My take away is that we want mod_dbd bindings in mod_lua, but we want the API to be more carefully crafted. i -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: Password caching (was: svn commit: r1427548)
- Original Message - On Wednesday 02 January 2013, Eric Covener wrote: On Wed, Jan 2, 2013 at 4:02 PM, Stefan Fritsch s...@sfritsch.de wrote: On Wednesday 02 January 2013, Jim Jagielski wrote: For *real* improvement, wouldn't storing in socache be the optimal method? Yes. I fear there may be some knee-jerk reaction like oh my god, they are keeping all the passwords in plain-text. But if it would be limited to the shmcb socache provider, and if the passwords would be cleared after some time of not being used, I don't see any real security problems. Any other opinions? For authentication, can you already opt-in to effectively this with the mod_authn_socache? No, mod_authn_socache only caches the lookup of the password hash. It avoids having to open the password file/dbm/whatever but it still calls apr_password_validate() every time. Maybe it should be extended to also cache the real password and the result of apr_password_validate()? Stupid question time: Why can't we store the password *hash* in the socache instead of the plain-text password? i -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: [VOTE] accept mod_macro as standard module in httpd
Le 03/01/2013 03:06, Eric Covener a écrit : I was preparing the IP clearance forms and noticed our original vote thread was more of a discussion. I wanted to record a formal vote here so I can link to it. Pending IP clearance... [+1] accept mod_macro as a standard module and responsibility for its maintenance [ +/- 0] don't care won't help [ -1] don't accept mod_macro as a standard module My +1 -- Eric Covener cove...@gmail.com +1 looks really interesting and useful CJ
Re: thread-safety of time conversion caches in util_time.c and mod_log_config.c
On Saturday 05 January 2013, Daniel Lescohier wrote:
apr_atomic_read32 is not implemented with a memory barrier. The
implementation of apr_atomic_read32 in the APR code base is just a
read from a pointer marked volatile. E.g., here is the
atomic/unix/builtins.c implementation:
APR_DECLARE(apr_uint32_t) apr_atomic_read32(volatile apr_uint32_t
*mem)
{
return *mem;
}
Sigh. I was too much focused on x86. There the compiler barrier caused
by the function call is enough. But you are right, on other
architectures these functions may also require cpu memory barriers.
The functions are meant to include the barriers, according to the
documentation in apr_atomic.h. So they should be fixed in apr.
Re: thread-safety of time conversion caches in util_time.c and mod_log_config.c
- Original Message -
On Saturday 05 January 2013, Daniel Lescohier wrote:
apr_atomic_read32 is not implemented with a memory barrier. The
implementation of apr_atomic_read32 in the APR code base is just a
read from a pointer marked volatile. E.g., here is the
atomic/unix/builtins.c implementation:
APR_DECLARE(apr_uint32_t) apr_atomic_read32(volatile apr_uint32_t
*mem)
{
return *mem;
}
Sigh. I was too much focused on x86. There the compiler barrier
caused
by the function call is enough. But you are right, on other
architectures these functions may also require cpu memory barriers.
on x86 … is enough - would it harm x86 to add CPU barriers, or
do we want to have # define distinctions per arch?
The functions are meant to include the barriers, according to the
documentation in apr_atomic.h. So they should be fixed in apr.
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.ga...@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: thread-safety of time conversion caches in util_time.c and mod_log_config.c
Sigh. I was too much focused on x86. There the compiler barrier caused by the function call is enough. But you are right, on other architectures these functions may also require cpu memory barriers. on x86 … is enough - would it harm x86 to add CPU barriers, or do we want to have # define distinctions per arch? ignore me, I just realized it's going to be different calls per arch anyway! -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: [Discuss] mod_lua and database connectivity
On 01/05/2013 10:49 AM, Igor Galić wrote: Implied semantics matter a LOT in API design. +1 Check your errors :-) I don't need to check errors, I just need to check whether 'rows' is a table or a nil value in the case of an error. I could've checked if 'err' was anything, but the result is the same. An API which returns (foo, err) should be error checked on the error, not the foo. This style of API will sometimes return a foo in a bad state, and an err to let you know. In your example this is fine, I am just being a pedant because if an API is designed a certain way, we should use it that way :-) My take away is that we want mod_dbd bindings in mod_lua, but we want the API to be more carefully crafted. i My attempt at humour seems to have failed, so I'll be more to the point. Yes, calling it acquire rather than open makes sense, and it's a good suggestion that I have applied to my draft. Regarding the return values of 'acquire' (dbacquire, as it's currently called), this, as well as the query/run (or should it be called select/query? I'm not sure, but running db:select(SELECT...) seems a bit redundant in my mind) will never return a 'bad state', they will return nil if an error occurred, followed by an error message. How one chooses to check for an error, whether it be checking the nil value or checking for an error message, the result will be the same. However, in my documentation addition to mod_lua, I have consistently made the examples check for an error message, so no need to worry there - I was only being brief in my example snippets in the previous email, apologies. Return values are as follows: r:dbacquire(type, connstring): DB handle on success, nil + error on failure (error is either can't connect, can't load driver or mod_dbd not loaded) db:query(SELECT ): Result set on success, nil + error on failure (syntax error, permission issue or db handle not connected to backend) db:run(DELETE ): Number of affected rows on success, nil + error on failure (same errors as :query) With regards to how :query should work, this could either be done synchronously, wherein all rows are fetched at once, or async where rows are fetched as needed. The sync way is rather easy, but could fill up more memory than needed, while the async has a smaller footprint but proves rather difficult to implement, as the darn dbd driver keeps wanting to free up the result set before it's finished being used (apr_dbd_get_row keeps segfaulting when I request a row that is out of bounds... :( ). Also,there is the consideration of what happens if you query a db, get a result set, close the db handle and try to fetch more rows - this would most likely result in a segfault, as the db handle would have been freed when you try to use it again (how to check that?). Also, getting the number of rows, or even doing: for k, v in pairs(rows) ... proves to be quite difficult with the async method. What I've pieced together so far would work something like this: local results, err = db:query(SELECT .) it not err then -- Async method here: local x = 1 local row = results(x) -- fetch row 1 while row do x = x + 1 row = results(x) -- fetch row 2,3,4,5...N end -- Sync method here: local rows = results() -- fetch all rows at once for index, row in pairs(rows) do end end As usual, suggestions and comments are most welcome! And as for the inject/prepare stuff, I'm working on a new approach to that as well, will keep you guys posted. With regards, Daniel.
Re: Password caching (was: svn commit: r1427548)
On Saturday 05 January 2013, Igor Galić wrote: No, mod_authn_socache only caches the lookup of the password hash. It avoids having to open the password file/dbm/whatever but it still calls apr_password_validate() every time. Maybe it should be extended to also cache the real password and the result of apr_password_validate()? Stupid question time: Why can't we store the password hash in the socache instead of the plain-text password? Because validating the password from the hash is slow. It has to be slow, in order to make it impossible to brute-force the password from the hash using today's graphics chips. A single cpu core of a core i7 @ 2.8Ghz can do this many password validations per second: crypt: 4157 (I have been told that this could be improved by reusing the struct crypt_data) md5crypt: 3552 (the current default algorithm) bcrypt5: 503 (cost setting 5, current default in htpasswd for bcrypt) bcrypt8:66 (cost setting 8, a common value for use of bcrypt in /etc/passwd) If the validation has to be done once per request, it severely limits the web server's performance. Of course with form based auth, this is much less of a problem than with basic auth, because the password has only to be validated during login. But I would still like to have a viable and secure solution for basic auth.
Re: event mpm and mod_status
On 05 Jan 2013, at 2:05 AM, Stefan Fritsch s...@sfritsch.de wrote: For 1., a better thread selection would definitely be a win. For 2. and 3., it is less obvious. +1. Just because in some cases a cache might not help, doesn't mean we shouldn't take advantage of the cache when it will help. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: thread-safety of time conversion caches in util_time.c and mod_log_config.c
I'd have to go back and review the Intel documentation to be sure, but for this particular algorithm, an explicit memory barrier may be required on Intel architecture, also. If I remember correctly, without a memory barrier, Intel arch only guarantees total memory ordering within one cache line. For this algorithm, we have an array of 16 cache_elements of 48 bytes each, so half of the cache_elements cross 64-byte cache lines. When reading the cache_element-key after the copy of the cache_element value, we need to make sure that the cache_element value read is ordered before the read of the cache_element-key, so one needs a memory barrier just before the read of the cache_element-key to guarantee the ordering. On Sat, Jan 5, 2013 at 5:08 AM, Igor Galić i.ga...@brainsware.org wrote: Sigh. I was too much focused on x86. There the compiler barrier caused by the function call is enough. But you are right, on other architectures these functions may also require cpu memory barriers. on x86 … is enough - would it harm x86 to add CPU barriers, or do we want to have # define distinctions per arch? ignore me, I just realized it's going to be different calls per arch anyway! -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: event mpm and mod_status
+1... a lot of little improvements can result in a BIG improvement. On Jan 5, 2013, at 8:34 AM, Graham Leggett minf...@sharp.fm wrote: On 05 Jan 2013, at 2:05 AM, Stefan Fritsch s...@sfritsch.de wrote: For 1., a better thread selection would definitely be a win. For 2. and 3., it is less obvious. +1. Just because in some cases a cache might not help, doesn't mean we shouldn't take advantage of the cache when it will help. Regards, Graham --
Re: Balancer persist and inherit stuff in trunk
I haven't created the patch yet... it seems backwards to generate a backport patchset unless what is currently in trunk is OK. There were some suggestions for improvement made regarding the 2.4 backport that ideally would have been noted and addressed in trunk first. I just want to avoid another go-around ;) On Jan 4, 2013, at 2:08 PM, Mikhail T. mi+t...@aldan.algebra.com wrote: Sorry -- I meant to send the below just to Jim, but messed-up the headers in Thunderbird -- and it ended up looking, as if Jim wrote it :( On 04.01.2013 14:06, j...@jagunet.com wrote: On 04.01.2013 13:48, Jim Jagielski wrote: Have people had a chance to test, review and try the balancer persist and inheritance stuff in trunk? I want to make sure that we have some level of verification and agreement there before I work on the backports for 2.4 ;) Could you give the link to the patch/issue? I'd be happy to test it with a custom-built 2.4.3 here. Thanks! -mi
Re: Balancer persist and inherit stuff in trunk
On 05.01.2013 10:30, Jim Jagielski wrote: I haven't created the patch yet... it seems backwards to generate a backport patchset unless what is currently in trunk is OK. I can drop in a patch into our 2.4.3 build relatively easily. Building (and testing) from trunk is a more serious undertaking. Yours, -mi
Re: Balancer persist and inherit stuff in trunk
On 04.01.2013 19:48, Jim Jagielski wrote: Have people had a chance to test, review and try the balancer persist and inheritance stuff in trunk? I want to make sure that we have some level of verification and agreement there before I work on the backports for 2.4 ;) I didn't see any changes with respect to two of my original comments: The Used counters (number of shared mem slots) in balancer manager drops to 0 after restart/reboot´with persist on. This seems strange. Not that Used does *not* have anything to do with request counting. Second the Elected counter is persisted but e.g. the traffic counter's not. This seems somewhat inconsistent. I have no strong opinion whether to persist statistics or not, but we might want to behave consistently. I did not observe any functional changes after my Mail from Dec. 14, right? Regards, Rainer
Re: [VOTE] accept mod_macro as standard module in httpd
On 1/2/2013 8:06 PM, Eric Covener wrote: I was preparing the IP clearance forms and noticed our original vote thread was more of a discussion. I wanted to record a formal vote here so I can link to it. Pending IP clearance... [+1] accept mod_macro as a standard module and responsibility for its maintenance [ +/- 0] don't care won't help [ -1] don't accept mod_macro as a standard module My +1 -- Eric Covener cove...@gmail.com Another +1 -- Daniel Ruggeri
Re: [Discuss] mod_lua and database connectivity
It was thus said that the Great Daniel Gruno once stated: With regards to how :query should work, this could either be done synchronously, wherein all rows are fetched at once, or async where rows are fetched as needed. The sync way is rather easy, but could fill up more memory than needed, while the async has a smaller footprint but proves rather difficult to implement, as the darn dbd driver keeps wanting to free up the result set before it's finished being used (apr_dbd_get_row keeps segfaulting when I request a row that is out of bounds... :( ). Also,there is the consideration of what happens if you query a db, get a result set, close the db handle and try to fetch more rows - this would most likely result in a segfault, as the db handle would have been freed when you try to use it again (how to check that?). Also, getting the number of rows, or even doing: for k, v in pairs(rows) ... proves to be quite difficult with the async method. What I've pieced together so far would work something like this: local results, err = db:query(SELECT .) it not err then -- Async method here: local x = 1 local row = results(x) -- fetch row 1 while row do x = x + 1 row = results(x) -- fetch row 2,3,4,5...N end -- Sync method here: local rows = results() -- fetch all rows at once for index, row in pairs(rows) do end end You could always create an interator for the results and hide the method (sync/async) behind it: function db:query(q) ... local function results_async() local function getnext(state) -- state is the db object return db:results_next(state) end return getnext,self end local function results_sync() local row = db:results_all(db) return pairs(row) end ... return results_async,err end local results, err = db:query(SELECT ... ) if not err then for row in results() do blah_de_blah_blah() end end Untested code and all that (so it may very be wrong, but the intent is there) -spc
Re: thread-safety of time conversion caches in util_time.c and mod_log_config.c
I was wrong about the Intel architecture: it has a pretty strong
memory-ordering guarantee. But other architectures, like PowerPC and ARM,
have a weak memory-ordering guarantee. Here is a good summary:
https://en.wikipedia.org/wiki/Memory_ordering. The doc in footnote 3 is a
good document to read.
I'm not sure we should include memory barriers inside the apr_atomic_read32
and apr_atomic_set32 functions, because you don't necessarily need a full
memory barrier on each read or set. Instead, perhaps we should add three
functions to APR:
1. apr_atomic_rmb(): read memory barrier.
2. apr_atomic_wmb(): write memory barrier.
3. apr_atomic_mb(): full memory barrier.
As a use-case, the new util_time.c algorithm could be changed to be:
For the read-from-cache portion:
const apr_uint32_t key = apr_atomic_read32(cache_element-key);
/* Above is done speculatively, no memory barrier used.
if (seconds == key seconds != 0) {
/* seconds == 0 may mean cache is uninitialized, so don't use cache
*/
*xt = cache_element-xt;
/* After copying xt, make sure cache_element was not marked invalid
* by another thread beginning an update, and that cache_element
* really contained data for our second.
* Requires memory barrier. */
apr_atomic_rmb();
if (apr_atomic_read32(cache_element-key)==seconds) {
xt-tm_usec = (int)apr_time_usec(t);
return APR_SUCCESS;
}
}
And the write-to-cache portion would be:
if (key == apr_atomic_cas32(cache_element-key, ~seconds, key))
{ /* We won the race to update this cache_element.
* Above marks cache_element as invalid by using ~seconds,
* because we are starting an update: it's the start of a
* transaction. */
cache_element-xt = *xt;
/* Finished copying, now update key with our key,
* ending the transaction. Need to use a
* memory barrier.
*/
apr_atomic_wmb();
apr_atomic_set32(cache_element-key, seconds);
}
On Sat, Jan 5, 2013 at 8:40 AM, Daniel Lescohier
daniel.lescoh...@cbsi.comwrote:
I'd have to go back and review the Intel documentation to be sure, but for
this particular algorithm, an explicit memory barrier may be required on
Intel architecture, also. If I remember correctly, without a memory
barrier, Intel arch only guarantees total memory ordering within one cache
line. For this algorithm, we have an array of 16 cache_elements of 48
bytes each, so half of the cache_elements cross 64-byte cache lines. When
reading the cache_element-key after the copy of the cache_element value,
we need to make sure that the cache_element value read is ordered before
the read of the cache_element-key, so one needs a memory barrier just
before the read of the cache_element-key to guarantee the ordering.
On Sat, Jan 5, 2013 at 5:08 AM, Igor Galić i.ga...@brainsware.org wrote:
Sigh. I was too much focused on x86. There the compiler barrier
caused
by the function call is enough. But you are right, on other
architectures these functions may also require cpu memory barriers.
on x86 … is enough - would it harm x86 to add CPU barriers, or
do we want to have # define distinctions per arch?
ignore me, I just realized it's going to be different
calls per arch anyway!
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.ga...@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: Password caching
On 05/01/2013 11:52, Igor Galić wrote: - Original Message - On Wednesday 02 January 2013, Eric Covener wrote: On Wed, Jan 2, 2013 at 4:02 PM, Stefan Fritsch s...@sfritsch.de wrote: On Wednesday 02 January 2013, Jim Jagielski wrote: For *real* improvement, wouldn't storing in socache be the optimal method? Yes. I fear there may be some knee-jerk reaction like oh my god, they are keeping all the passwords in plain-text. But if it would be limited to the shmcb socache provider, and if the passwords would be cleared after some time of not being used, I don't see any real security problems. Any other opinions? For authentication, can you already opt-in to effectively this with the mod_authn_socache? No, mod_authn_socache only caches the lookup of the password hash. It avoids having to open the password file/dbm/whatever but it still calls apr_password_validate() every time. Maybe it should be extended to also cache the real password and the result of apr_password_validate()? Stupid question time: Why can't we store the password *hash* in the socache instead of the plain-text password? i Igor, that is exactly what Stefan is says already happens with mod_authn_socache, unless I grossly misread... I'd be +1 allowing for a directive to hash the plaintext in socache, if it wasn't the default. I'd probably be +0 to it being the default, but only because I don't see myself as having tuits to look closely enough at shmcb cache to really understand the security implications for myself; but if the sysadmin is already opt-ing in for any sort of authentication caching, then (s)he already is aware of a hypothetical chance for a security compromise on the system to some degree or another. Issac
