You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Jon Travis <jt...@covalent.net> on 2001/08/17 19:55:04 UTC
[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) {
Re: [PATCH] apr_uri_unparse_components monthly reminder
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Fri, Aug 17, 2001 at 10:55:04AM -0700, Jon Travis wrote:
> 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.
Committed. Thanks. You should probably resend once a week not once a
month. =-) -- justin
Re: [PATCH] apr_uri_unparse_components monthly reminder
Posted by Justin Erenkrantz <je...@ebuilt.com>.
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.)
Okay, I don't think apr-util's version is affected by this (so 2.0 is
fine).
Apache 1.3 definitely is. Consider the case where where uptr->path is
NULL. This stops the string from expanding correctly.
The proposed patch looks correct. Should I apply to apache-1.3? I
think I need some +1s to commit it. But, I'm not sure. -- justin
Index: util_uri.c
===================================================================
RCS file: /home/cvs/apache-1.3/src/main/util_uri.c,v
retrieving revision 1.35
diff -u -r1.35 util_uri.c
--- util_uri.c 2001/04/08 07:50:02 1.35
+++ util_uri.c 2001/08/18 20:31:14
@@ -246,8 +246,9 @@
/* We must ensure we don't put out a hier_part and a rel_path
* */
if (j && uptr->path && *uptr->path != '/')
parts[j++] = "/";
-
- parts[j++] = uptr->path;
+
+ if (uptr->path)
+ parts[j++] = uptr->path;
if (!(flags & UNP_OMITQUERY)) {
if (uptr->query) {
Re: [PATCH] apr_uri_unparse_components monthly reminder
Posted by Justin Erenkrantz <je...@ebuilt.com>.
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.)
I'll look at this tomorrow and take a stab at fixing it if it hasn't
already been fixed. -- justin
Re: [PATCH] apr_uri_unparse_components monthly reminder
Posted by Jon Travis <jt...@covalent.net>.
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" <jt...@covalent.net>
> To: <de...@apr.apache.org>
> 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: <ap...@apache.org>
> Reply-To: apache-bugdb@apache.org
> Date: 17 Aug 2001 06:24:27 -0000
> From: Dongqiang Bai <ba...@dreamarts.co.jp>
> Reply-To: bai@dreamarts.co.jp
> To: submit@bugz.apache.org
> 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: bai@dreamarts.co.jp
> >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 <ap...@Apache.Org> 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! ]
>
>
>
Re: [PATCH] apr_uri_unparse_components monthly reminder
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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" <jt...@covalent.net>
To: <de...@apr.apache.org>
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) {
>