Return-Path: 
 <apreq-dev-return-519-apmail-httpd-apreq-dev-archive=httpd.apache.org@httpd.apache.org>
Delivered-To: apmail-httpd-apreq-dev-archive@httpd.apache.org
Received: (qmail 71279 invoked by uid 500); 26 Nov 2002 16:51:59 -0000
Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:apreq-dev@httpd.apache.org>
List-Help: <mailto:apreq-dev-help@httpd.apache.org>
List-Unsubscribe: <mailto:apreq-dev-unsubscribe@httpd.apache.org>
List-Subscribe: <mailto:apreq-dev-subscribe@httpd.apache.org>
Delivered-To: mailing list apreq-dev@httpd.apache.org
Delivered-To: moderator for apreq-dev@httpd.apache.org
Received: (qmail 94715 invoked from network); 26 Nov 2002 13:07:53 -0000
X-Original-Recipient: apreq-dev@httpd.apache.org
Message-ID: <3DE37267.3010607@svenskabutiker.se>
Date: Tue, 26 Nov 2002 14:08:55 +0100
From: Martin Nilsson <martin@svenskabutiker.se>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Joe Schaefer <joe+apache@sunstarsys.com>
CC: modperl list <modperl@perl.apache.org>, macosx list <macosx@perl.org>,
   apreq list <apreq-dev@httpd.apache.org>
Subject: Re: libapreq-1.1 Release Candidate 1
References: <m3k7j1cjgo.fsf@mumonkan.sunstarsys.com>
Content-Type: multipart/mixed;
 boundary="------------030301050000000608010003"
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

This is a multi-part message in MIME format.
--------------030301050000000608010003
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Joe Schaefer wrote:
> The apreq developers are planning a maintenance release of
> libapreq-1.1.  This version does not include support for
> modperl-2, but it does address some outstanding problems in
> 1.0:

I have made the below patch to make Apache::Request behave like CGI.pm 
when parsing multi-valued http POST data. Without the patch the matching 
of the variable names is case insensitive this results in a multi valued 
list instead of two separate hash entries if the following fragment is 
posted.

<input type="hidden" name="GOTO" value="up">
<input type="hidden" name="goto" value="down">

Since the keys in perl hashes are case sensitive it makes no sense to 
believe that the above two keys should create a multivalued enty and not 
two entries, one with key 'GOTO' and the other with 'goto'.

To make matters worse actual case used for the resulting multivalued key 
  is only dependent on which field that was parsed first!

	/Martin


-- 
Martin Nilsson, Civilingenj�r M.Sc. CS&E
Svenska Butiker AB,
S:t Larsv�g 44, 222 70 Lund, Sweden
martin@svenskabutiker.se
Phone: +46-46-304130
http://www.svenskabutiker.se

--------------030301050000000608010003
Content-Type: text/plain;
 name="libapreq-1.0.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="libapreq-1.0.diff"

--- Request/Request.xs.org	Sun Jan 20 18:27:35 2002
+++ Request/Request.xs	Wed Sep 11 18:11:11 2002
@@ -400,7 +400,7 @@
 	        array_header *arr  = ap_table_elts(req->parms);
 	        table_entry *elts = (table_entry *)arr->elts;
 	        for (i = 0; i < arr->nelts; ++i) {
-	            if (elts[i].key && strcaseEQ(elts[i].key, key))
+	            if (elts[i].key && strEQ(elts[i].key, key))
 	            	XPUSHs(sv_2mortal(newSVpv(elts[i].val,0)));
 	        }
 	    }
@@ -429,7 +429,7 @@
 	           if (!elts[i].key) continue;
 		    /* simple but inefficient uniqueness check */
 		    for (j = 0; j < i; ++j) { 
-		        if (strcaseEQ(elts[i].key, elts[j].key))
+		        if (strEQ(elts[i].key, elts[j].key))
 			    break;
 		    }
 	            if ( i == j )

--------------030301050000000608010003--