Re: mod_ssl/input filter review needed

2004-06-03 Thread Justin Erenkrantz
--On Wednesday, June 2, 2004 12:12 PM +0100 Joe Orton <[EMAIL PROTECTED]> wrote: The approach I'm using is a new input filter which runs above (before) the HTTP input filter, and waits for an EOS, then does the SSL handshake. All the data must be read from the socket before starting the handshak

Re: Dechunking code in Apache 2.0.49

2004-06-03 Thread Graham Leggett
Mathias Herberts wrote: What is the position of the Apache community on the passing of 'hop by hop' headers to origin servers by mod_proxy? The code in proxy_http.c says 'RFC2616 13.5.1 says we should strip these headers', but RFC 2616 13.5.1 defines 'Hop-by-hop headers, which are meaningful onl

Dechunking code in Apache 2.0.49

2004-06-03 Thread Mathias Herberts
Hi, I've been deploying Apache 1.3 instances for many years now, relying heavily on the mod_proxy / mod_rewrite couple to build our HTTP backbone. In the past year I've met a problem with the proxying of requests made by MIDP (mobile devices) clients. Those requests were using 'Transfer-Encodin

Re: [PATCH 1.3] Proxied Server:/Date: headers

2004-06-03 Thread TOKILEY
> William Rowe wrote... > >I'd worked with some interesting java and cgi code which implements >proxy behavior, as opposed to using a compiled-in module such as >mod_proxy.  In order to properly pass on the Server: and Date: headers >(which are owned by the origin server), this patch tests for the

Re: ErrorHeader directive...

2004-06-03 Thread André Malo
* "Brad Nicholes" <[EMAIL PROTECTED]> wrote: > Since there is a proposal to backport this directive to the 2.0 branch, > would it make more sense to rename it to something else and avoid the > confusion before it is backported? It just seems a little strange to be > getting an error heade

Re: ErrorHeader directive...

2004-06-03 Thread Brad Nicholes
Since there is a proposal to backport this directive to the 2.0 branch, would it make more sense to rename it to something else and avoid the confusion before it is backported? It just seems a little strange to be getting an error header back in a successful response. If the point is to allo

Re: x86_64 atomics and linux

2004-06-03 Thread Joe Orton
On Wed, Jun 02, 2004 at 03:40:52PM -0400, Brian Akins wrote: > AFAIK, the linux x86 atomic stuff can be used unchanged on Linux > x86_64. This is based on my digging in the kernel source. All the > "functions" apr uses are identical. This is already done for APR HEAD: a backport would probably