>Number: 1004 >Category: apache-api >Synopsis: request_config field in request_rec is moderately bogus >Confidential: no >Severity: non-critical >Priority: medium >Responsible: apache (Apache HTTP Project) >State: open >Class: sw-bug >Submitter-Id: apache >Arrival-Date: Sun Aug 17 04:50:01 1997 >Originator: [EMAIL PROTECTED] >Organization: apache >Release: all through 1.3 >Environment: n/a >Description: For various reasons we have defined mechanisms for almost every field in request_rec to be merged or passed down into subrequests, or promoted from a subrequest into the parent request. There is one very notable exception, request_config. This field (not used at all by stock modules) contains arbitrary binary data, and the API does not define any semantics for merging/promoting it. Modules would have an extremely hard time using this field because subrequests are ubiquitous.
A similar comment could be made about r->notes. But that is just a table and is easy to define merging semantics without api additions. >How-To-Repeat: >Fix: I tend to lean towards removing request_config. Unless someone can demonstrate a use for it ... in which case we could define some merging functions in the api >Audit-Trail: >Unformatted:
