Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 9761 invoked from network); 26 Sep 2007 16:06:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 26 Sep 2007 16:06:03 -0000 Received: (qmail 17001 invoked by uid 500); 26 Sep 2007 16:05:49 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 16949 invoked by uid 500); 26 Sep 2007 16:05:49 -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: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 16938 invoked by uid 99); 26 Sep 2007 16:05:49 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Sep 2007 09:05:49 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [140.211.11.9] (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 26 Sep 2007 16:05:58 +0000 Received: (qmail 8058 invoked by uid 2161); 26 Sep 2007 16:05:38 -0000 Received: from [192.168.2.4] (euler.heimnetz.de [192.168.2.4]) by cerberus.heimnetz.de (Postfix on SuSE Linux 7.0 (i386)) with ESMTP id 6F6401721C for ; Wed, 26 Sep 2007 18:05:26 +0200 (CEST) Message-ID: <46FA8353.1040002@apache.org> Date: Wed, 26 Sep 2007 18:05:39 +0200 From: Ruediger Pluem User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: dev@httpd.apache.org Subject: Re: Patching PR#13986 References: <20070926160936.7ed69b28@grimnir> In-Reply-To: X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org On 09/26/2007 05:14 PM, Joshua Slive wrote: > On 9/26/07, Nick Kew wrote: >> We really need to fix this issue of inappropriate DefaultTypes. >> >> An approach that deals with this without loss of back-compatibility >> is to hand the decision to systems administrators: >> >> #to suppress setting content-type when the server has no information >> DefaultType ! > > +1 on concept, but I'd prefer DefaultType none, which is more readable > and I believe equally unlikely to show up in a real content-type. Also +1 on concept, but 1. I am unsure if it is ok to sent parts of a multipart/byteranges response without a Content-type. RFC2616 19.2 says: "The multipart/byteranges media type includes two or more parts, each with its own Content-Type and Content-Range fields." OTOH the words MUST and SHOULD are not used here. 2. Remove the tabs from the patch ;-) Regards R�diger