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
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
+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
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
+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
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
- 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?
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
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:
- 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
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 #
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
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
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.
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.
+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
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
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.
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
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
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,
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
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
23 matches
Mail list logo