Uhm. My patch is totally seperate from this bug report, aside from the fact that they both occur within the unparse_uri_components function.
-- Jon On Fri, Aug 17, 2001 at 01:21:31PM -0500, William A. Rowe, Jr. wrote: > Jon, > > can you take a look at the attached bug report, and assure that your patch > handles this case correctly before we apply it today? I'd like to lick all > the bugs, and wanted to be sure that this report is dead as well (on 2.0.) > > Bill > > > > ----- Original Message ----- > From: "Jon Travis" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Friday, August 17, 2001 12:55 PM > Subject: [PATCH] apr_uri_unparse_components monthly reminder > > > > This is a reminder, sent out once a month, about a previous APR > > patch submission. It includes the patch, description, and how to > > use it to fix broken code. > > > > Original patch post date: Jul-18-2001 > > > > Description: > > > > apr_uri_unparse_components can unparse components into an invalid > > URI. If the components contain either a user or password, the > > unparsed URI will always contain an '@' symbol. This is incorrect, > > since the UNP_OMITPASSWORD and UNP_OMITUSER flags can affect > > this functionality. I.e. if the components contain either a user > > or password, and flags to omit both the user and password from the > > unparsed URI are given, the output should contain no '@' symbol. > > > > The patch: > > > > ? uri/patch.diff > > Index: uri/apr_uri.c > > =================================================================== > > RCS file: /home/cvspublic/apr-util/uri/apr_uri.c,v > > retrieving revision 1.6 > > diff -u -u -r1.6 apr_uri.c > > --- uri/apr_uri.c 2001/06/13 22:56:23 1.6 > > +++ uri/apr_uri.c 2001/07/23 17:21:39 > > @@ -139,7 +139,9 @@ > > (uptr->password && !(flags & UNP_OMITPASSWORD)) > > ? ((flags & UNP_REVEALPASSWORD) ? uptr->password : "XXXXXXXX") > > : "", > > - "@", NULL); > > + ((uptr->user && !(flags & UNP_OMITUSER)) || > > + (uptr->password && !(flags & UNP_OMITPASSWORD))) ? "@" > > + : "", NULL); > > > > /* Construct scheme://site string */ > > if (uptr->hostname) { > > > Return-Path: <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > Date: 17 Aug 2001 06:24:27 -0000 > From: Dongqiang Bai <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Subject: apache-api/8195: ap_unparse_uri_components() steals ->query info > when ->path is NULL > > > >Number: 8195 > >Category: apache-api > >Synopsis: ap_unparse_uri_components() steals ->query info when ->path > >is NULL > >Confidential: no > >Severity: non-critical > >Priority: medium > >Responsible: apache > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: apache > >Arrival-Date: Thu Aug 16 23:30:01 PDT 2001 > >Closed-Date: > >Last-Modified: > >Originator: [EMAIL PROTECTED] > >Release: 1.3.20 > >Organization: > apache > >Environment: > OS: Linux(acturally all OS) > PATCH: without any patch > Compiler: gcc(actually un-related) > >Description: > I'm writing apache modules using ap_* functions. > > Looking at such html tag: > <FORM action="?act=1"> > > Use ap_parse_uri_componets() to parse the URI "?act=1", then use > ap_unparse_uri_components() to recover the URI, you will get the different > results, and the convert=>revert result is an empty string "". > > This was not a problem in apache_1.3.14. > >How-To-Repeat: > Look at the source code of apache_1.3.20/src/main/util_uri.c:line 250 is > better. > Or insert following test code into apache to be called and do debug: > ------------------ > void test_ap_unparse_uri_components(pool *anypool) > { > uri_components *uptr = ap_pcalloc(anypool, sizeof(uri_components)); > int status = ap_parse_uri_components(anypool, "?act=1", uptr); > char *new_uri = ap_unparse_uri_components(anypool, uptr, 0); > > // verify the new_uri became empty here > if (strlen(new_uri) == 0) > // this shows the problem > exit(1); > } > >Fix: > Add one line before 250 line of util_uri.c: > line 250: +) if (uptr->path) > line 251: ) parts[j++] = uptr->path; > >Release-Note: > >Audit-Trail: > >Unformatted: > [In order for any reply to be added to the PR database, you need] > [to include <[EMAIL PROTECTED]> in the Cc line and make sure the] > [subject line starts with the report component and number, with ] > [or without any 'Re:' prefixes (such as "general/1098:" or ] > ["Re: general/1098:"). If the subject doesn't match this ] > [pattern, your message will be misfiled and ignored. The ] > ["apbugs" address is not added to the Cc line of messages from ] > [the database automatically because of the potential for mail ] > [loops. If you do not include this Cc, your reply may be ig- ] > [nored unless you are responding to an explicit request from a ] > [developer. Reply only with text; DO NOT SEND ATTACHMENTS! ] > > >
