Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 90055 invoked from network); 8 Dec 2004 18:14:37 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 8 Dec 2004 18:14:37 -0000 Received: (qmail 33861 invoked by uid 500); 8 Dec 2004 18:14:28 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 33780 invoked by uid 500); 8 Dec 2004 18:14:28 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 33625 invoked by uid 99); 8 Dec 2004 18:14:27 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FORGED_RCVD_HELO X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from devonshire.concentric.net (HELO devonshire.cnchost.com) (207.155.248.12) by apache.org (qpsmtpd/0.28) with ESMTP; Wed, 08 Dec 2004 10:14:26 -0800 Received: from rcsv650.rowe-clan.net (c-24-13-128-132.client.comcast.net [24.13.128.132]) by devonshire.cnchost.com id NAA28978; Wed, 8 Dec 2004 13:14:22 -0500 (EST) [ConcentricHost SMTP Relay 1.17] Errors-To: Message-Id: <6.2.0.14.2.20041208115354.05a2b6d0@pop3.rowe-clan.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 08 Dec 2004 11:56:10 -0600 To: dev@httpd.apache.org From: "William A. Rowe, Jr." Subject: Re: Testing TLS Upgrade (was: Re: Patch for bug 18757 breaks TLS upgrade) Cc: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N At 10:10 AM 12/8/2004, Brad Nicholes wrote: > FYI, if anybody else is interesting is testing the TLS upgrade >functionality, there is a small test utility >(http://www.apache.org/~bnicholes/tlsupgrade.c) that can be used to send >an upgradeable GET or POST request. It seems to me we can make ab.c TLS upgrade-aware by; 1. recognizing the -s flag in conjunction with http: - that would set the ssl preference client-side. (This would not alter the behavior of https:, or of -s without a scheme.) 2. recognize upgrade-required and promote an http: connection to SSL when the server-side demands it. Sane? Bill