Received: (qmail 73886 invoked by uid 501); 23 Sep 2000 14:05:49 -0000
Message-Id: <20000923140549.73885.qmail@locus.apache.org>
Date: 23 Sep 2000 14:05:49 -0000
From: Michel Marti <mma@gmx.net>
Reply-To: mma@gmx.net
To: submit@bugz.apache.org
Subject: unparsed_uri & parse_uri doesn't contain scheme, port, hostname,etc.
X-Send-Pr-Version: 3.110

>Number:         6568
>Category:       apache-api
>Synopsis:       unparsed_uri & parse_uri doesn't contain scheme, port, hostname,etc.
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    apache
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          support
>Submitter-Id:   apache
>Arrival-Date:   Sat Sep 23 07:10:00 PDT 2000
>Closed-Date:    Mon Sep 25 15:57:45 PDT 2000
>Last-Modified:  Mon Sep 25 15:57:45 PDT 2000
>Originator:     mma@gmx.net
>Release:        1.3.9
>Organization:
>Environment:
Linux 2.2.14
>Description:
Im currently writting a request handler for apache in C. The problem I have
is that the field "unparsed_uri" in the request is exactly the same as the 
"parsed" uri, neither scheme, port, hostname, query, etc. are contained in
it. Also, the parsed_uri structure (uri_components) only contains "path", all 
other fields (scheme, hostname, etc) are null. E.g. if I request 
"http://myhost/example/index.html", both "uri" and "unparsed_uri"
contain "/example/index.html". I already checked your problem report db and
couldn't find any information explaining this behaviour. 
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open-closed
State-Changed-By: fanf
State-Changed-When: Mon Sep 25 15:57:44 PDT 2000
State-Changed-Why:
The problem that you describe is s result of the way that
HTTP works combined with the way that the URI parsing code
works. The parsing code parses the URI that comes in on the
HTTP request line, and in the vast majority of cases this
doesn't include the scheme, host, or port. The URI parsing
code leaves NULL those parts of the URI that are not present,
typically scheme, host, & port, and frequently query. It is
up to more high-level parts of the server to decide what the
right value for the missing parts is -- see for example the
UseCanonicalName directive. Your module should use other
fields in the request_rec rather than the raw URI information
so that it can benefit from sanity checking and other logic
in the core that does the right thing with the parsed URI.
This should also improve the way that it interacts with other
modules, especially mod_rewrite.

>Unformatted:
 [In order for any reply to be added to the PR database, you need]
 [to include <apbugs@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!     ]