build httpd/apr on vista with latest SDK

2007-02-13 Thread Issac Goldstand
Has anyone successfully built httpd on Vista with the SDK and bundled compiler? Issac

Re: build httpd/apr on vista with latest SDK

2007-02-13 Thread William A. Rowe, Jr.
Issac Goldstand wrote: Has anyone successfully built httpd on Vista with the SDK and bundled compiler? Bundled compiler? If Vista or the most recent SDK includes a C compiler, it would be news to me. Pointers?

Re: build httpd/apr on vista with latest SDK

2007-02-13 Thread Issac Goldstand
You read correctly. 'tis sweet indeed. I think it's the compilers that come with vs 2005 express editions. It includes compilers for x86, x64 and IA64 (all are x86 binaries and cross-compile for the target platform, if I understood correctly - as I don't have any x64 OS installed, I haven't

Re: build httpd/apr on vista with latest SDK

2007-02-13 Thread William A. Rowe, Jr.
Issac Goldstand wrote: I think it's the compilers that come with vs 2005 express editions. Then the answer I suppose is ... yes. 2005 compiles are working fine. FWIW, if you are trying to build from the GUI - that's it's own can of worms, it mis-parses the RC flags from the .dsp upon

Re: build httpd/apr on vista with latest SDK

2007-02-13 Thread Issac Goldstand
William A. Rowe, Jr. wrote: Issac Goldstand wrote: I think it's the compilers that come with vs 2005 express editions. Then the answer I suppose is ... yes. 2005 compiles are working fine. FWIW, if you are trying to build from the GUI - that's it's own can of worms, it mis-parses the

Re: Limiting response body length

2007-02-13 Thread Dziugas Baltrunas
Hi list, thanks for the replies. Looks like squid in case Content-Length response header is missing, does it's limitation in a hard way (snip from src/client_side.c): } else if (clientReplyBodyTooLarge(http, http-out.offset - 4096)) { /* 4096 is a margin for the HTTP headers included

Re: mod_cache: MISS or HIT

2007-02-13 Thread Dziugas Baltrunas
Hi, I was looking for something more reliable so I now realize it will require patching of mod_cache.c by adding some flag (i.e. setting some key r-notes, registering mod_log_config modifier via log_pfn_register or similar). On 2/12/07, Joshua Slive [EMAIL PROTECTED] wrote: On 2/12/07, Dziugas

Re: Limiting response body length

2007-02-13 Thread Ivan Ristic
On 2/13/07, Dziugas Baltrunas [EMAIL PROTECTED] wrote: Hi list, thanks for the replies. Looks like squid in case Content-Length response header is missing, does it's limitation in a hard way (snip from src/client_side.c): } else if (clientReplyBodyTooLarge(http, http-out.offset - 4096)) {

Re: Limiting response body length

2007-02-13 Thread Nick Kew
On Tue, 13 Feb 2007 11:30:32 + Ivan Ristic [EMAIL PROTECTED] wrote: No. If there's no C-L ModSecurity will count the bytes as they arrive. If there are too many the entire response will be blocked with 500 (and the error page sent to the client). That's a tradeoff you make against

Re: [VOTE] does mod_python want to be a TLP

2007-02-13 Thread Jim Gallacher
Gregory (Grisha) Trubetskoy wrote: Sorry - for technical reasons (serious home server crash) I missed this thread entirely, and for the same reason i'm lagging on the releasing mod_python that's ready to go. I am for making mod_python a TLP, and I also support Jim's suggestion of making it

Re: Limiting response body length

2007-02-13 Thread Ivan Ristic
On 2/13/07, Nick Kew [EMAIL PROTECTED] wrote: On Tue, 13 Feb 2007 11:30:32 + Ivan Ristic [EMAIL PROTECTED] wrote: No. If there's no C-L ModSecurity will count the bytes as they arrive. If there are too many the entire response will be blocked with 500 (and the error page sent to the

Enabling arbitrary/unregistered methods for 2.0

2007-02-13 Thread Rodent of Unusual Size
Here's a patch to allow the Script directive to handle arbitrary (e.g., site-specific or experimental) methods. Current 2.0 behaviour is 'if it's not something hard-coded into me, it's rubbish and gets tossed.' I notice that this functionality already exists in trunk, so this is essentially a

Redesigning Limit from the ground up.

2007-02-13 Thread William A. Rowe, Jr.
As originally conceived, Limit METH METH2 was designed to handle a very limited (once 30, now 62) different possible methods and assign them a specific Satisfy/Require/Allow/Deny/Order directive pattern that otherwise has no corresponding value for the un-Limit'ed method possibilities. The model

Re: Redesigning Limit from the ground up.

2007-02-13 Thread Nick Kew
On Tue, 13 Feb 2007 14:00:09 -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: As originally conceived, Limit METH METH2 was designed to handle a very limited (once 30, now 62) different possible methods and assign them a specific Satisfy/Require/Allow/Deny/Order directive pattern that

Re: Core vote for 3.3.1 stable release

2007-02-13 Thread Gregory (Grisha) Trubetskoy
OK, sorry for the delay, the files should be out there shortly, the web page and announcement should follow shortly. In the process learned that it's not the end of the world if your PGP key expires, the expiration date can be changed :) Grisha On Mon, 5 Feb 2007, Jim Gallacher wrote:

Re: Enabling arbitrary/unregistered methods for 2.0

2007-02-13 Thread Ruediger Pluem
On 02/13/2007 08:37 PM, Rodent of Unusual Size wrote: Here's a patch to allow the Script directive to handle arbitrary (e.g., site-specific or experimental) methods. Current 2.0 behaviour is 'if it's not something hard-coded into me, it's rubbish and gets tossed.' I notice that this

Re: Redesigning Limit from the ground up.

2007-02-13 Thread William A. Rowe, Jr.
Nick Kew wrote: On Tue, 13 Feb 2007 14:00:09 -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: The fundamental weakness of Limit is that it requires a module to cooperate proactively, and many modules don't. That gives it different semantics to other standard containers. Yes, that is

Re: Redesigning Limit from the ground up.

2007-02-13 Thread Nick Kew
On Tue, 13 Feb 2007 15:46:38 -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: I disagree. Limit is far too firmly established to change its semantics. Either we keep it as-is (warts and all) or we scrap it, and generate a startup error that advises the user of alternatives. Well,

Re: Redesigning Limit from the ground up.

2007-02-13 Thread Joshua Slive
On 2/13/07, Nick Kew [EMAIL PROTECTED] wrote: Location /limited/ methods=GET POST HEAD I like that a lot. It makes it clear that methods is an option (and hence doesn't generally need to be there), and skirts the whole ordering mess you get by adding a Method container. Directory /dir/

3.0 - Introduction

2007-02-13 Thread Paul Querna
I believe the httpd project is ready for a push towards the next major version. I believe everyone involved has learned many things from 2.x. I wasn't here for all of the early 2.x development, so it is very easy to say I am naive in the scope of something like pushing for 3.0. Today, I view

3.0 - Proposed Goals

2007-02-13 Thread Paul Querna
So, I've been kicking around some ideas about where I personally would like trunk to go for a couple months now. My personal goals for 3.0: - Write some cool stuff, that is fun to hack on. - Create an environment that encourages others to contribute, A project this large cannot and should not

3.0 - Proposed Requirements

2007-02-13 Thread Paul Querna
This proposed list of requirements for a 3.0 platform. this list enables a 'base' level of performance and design decisions to be made. If others can make designs work with 'lessor' requirements, all the better, but I'm not worried about it. Proposed Requirements: - C99 Compiler. - High

Re: 3.0 - Introduction

2007-02-13 Thread Jorge Schrauwen
On 2/14/07, Paul Querna [EMAIL PROTECTED] wrote: I personally believe the push for 3.0 needs to be focused on how to create a positive scratch your own itch for most of the developer. So, in that spirit, what bothers everyone else about 2.x? - Things I find lacking in 2.x are like you said