Patch for 2.0.54 + OpenSSL 0.9.8

2005-07-05 Thread Georg v. Zezschwitz
Hi, the OpenSSL team will pretty soon release 0.9.8 as stable release. However, currently 2.0.54 cannot be built with 0.9.8beta6, as a pem.h-definition has changed. The OpenSSL-team considers this renaming as a bug correction, so compilation of mod_ssl will go on to fail. OpenSSL 0.9.8 will

Re: Patch for 2.0.54 + OpenSSL 0.9.8

2005-07-05 Thread William A. Rowe, Jr.
Georg, thank you for the patch. It looks appropriate, to me, so I'll commit to 2.1.x and (if I can get two more +1's, folks???) I'll also apply to 2.0.55 before we roll in the next day. Bill At 07:32 AM 7/5/2005, Georg v. Zezschwitz wrote: Hi, the OpenSSL team will pretty soon release

[PATCH] Allow for internal OpenSSL Session Cache

2005-07-05 Thread Jim Jagielski
I've run into this with some broken browsers. Basically, they require a non-null SessionID in the SSL transaction. If, for whatever reason, we disable the external SSL Session Cache, these browsers reports errors when connecting to the SSL vhost. This adds a new argument to SSLSessionCache which

Re: [PATCH] Allow for internal OpenSSL Session Cache

2005-07-05 Thread Paul Querna
Jim Jagielski wrote: I've run into this with some broken browsers. Basically, they require a non-null SessionID in the SSL transaction. If, for whatever reason, we disable the external SSL Session Cache, these browsers reports errors when connecting to the SSL vhost. This adds a new argument

Re: [PATCH] Allow for internal OpenSSL Session Cache

2005-07-05 Thread Jim Jagielski
On Jul 5, 2005, at 1:41 PM, Paul Querna wrote: Jim Jagielski wrote: I've run into this with some broken browsers. Basically, they require a non-null SessionID in the SSL transaction. If, for whatever reason, we disable the external SSL Session Cache, these browsers reports errors when

Philosophy, empty body still a request body?

2005-07-05 Thread William A. Rowe, Jr.
RFC2616 says TRACE doesn't accept a body. Patches I'd committed to 1.3.x and working on 2.1.x (to port to 2.0.x) enforce this with TraceEnable On. But what about a 0-byte body? Content-Length: 0 Transfer-Encoding: chunked 0 both imply a body, with no body to follow. Should this case be

Re: Philosophy, empty body still a request body?

2005-07-05 Thread Ivan Ristic
On 7/5/05, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: RFC2616 says TRACE doesn't accept a body. Patches I'd committed to 1.3.x and working on 2.1.x (to port to 2.0.x) enforce this with TraceEnable On. But what about a 0-byte body? I think it is a body. Yes, it is only 0 bytes long but

[Patch 1.3] Strict proxy C-L / T-E conformance

2005-07-05 Thread William A. Rowe, Jr.
The attached patch restricts T-E responses to 'chunked', and discards C-L in that case, setting the response to nocache as a just-in-case. It also adds a note in case anyone wants to use connection keep-alive, warning of dire circumstances. Comments/votes? Bill

[Patch 1.3] Strict proxy C-L / T-E conformance

2005-07-05 Thread William A. Rowe, Jr.
Attached is the mystery patch [omitted from the last note - whoops]. IMHO we should apply the same to ap_http_filter() in 2.1's http_filters.c Bill At 10:35 PM 7/5/2005, William A. Rowe, Jr. wrote: The attached patch restricts T-E responses to 'chunked', and discards C-L in that case, setting