You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apreq-dev@httpd.apache.org by Joe Schaefer <jo...@sunstarsys.com> on 2003/11/11 05:01:34 UTC
[ANNOUNCE] libapreq2-2.01_03-dev released
The following message is a courtesy copy of an article
that has been posted to gmane.comp.apache.mod-perl as well.
The uploaded file
libapreq2-2.01_03-dev.tar.gz
has entered CPAN as
file: $CPAN/authors/id/J/JO/JOESUF/libapreq2-2.01_03-dev.tar.gz
size: 458218 bytes
md5: 736b4da910a221d05479a69b1e18e02d
CURRENT RELEASE NOTES:
- This is a developer release, indicated by the "-dev" suffix
on the version string. We believe the core interfaces to be stable,
but some portions of the API may still need significant modification.
Thus, binary/source compatibility may be broken from one developer
release to the next. In particular the version numbering rules specified
at
http://apr.apache.org/versioning.html
do not apply to developer releases.
CHANGES:
@section v2_01_dev Changes with libapreq2-2.01-dev
- November 7, 2003 - build system [joes]
Skip Apache::Test tests in env/ when Apache::Test is unavailable.
This allows the C API to be build and installed without requiring
Apache::Test (it is still a requirement for compiling the perl glue).
- November 7, 2003 - C API mod_apreq.c [joes]
Parser errors were creeping into the return value of apreq_filter,
which breaks the "transparent tee" paradigm. This caused bogus
"400 Bad Request" responses (first reported by Vladimir Dudo)
to occur when libapreq2 was used by an output filter during a GET
request (handled by apache2's default handler). The test suite
has been updated accordingly.
- October 26, 2003 - C API [joes]
Incorporate libapreq_cgi into libapreq2 as the default environment,
and add apreq_env_t and initializer apreq_env_module() to manage the
environment at runtime (determining the environment at load-time
was problematic on non-ELF systems).
@section v2_0_0 Changes with libapreq2-2.00-dev
- October 24, 2003 - C API: libapreq_cgi.c [randyk, joes]
CGI environment defined by env/libapreq_cgi.c is functional
(with tests added to env/t). This library may soon be incorporated
directly into libapreq2 as a default enviroment.
- October 23, 2003 - C API: mod_apreq.c [joes]
Added ctx->saw_eos to ensure we don't read from upstream filters
after receiving an eos bucket. Otherwise it was possible for
two eos buckets to appear when a prefetch read is involved, which
breaks other modules like mod_proxy. This bug was uncovered by
Philippe Chiasson. mod_apreq's apreq_env_majic_number bumped to
reflect the added fixes.
- October 17, 2003 - configure: --enable-perl-glue [joes]
The --enable-perl-glue option integrates the perl glue into the
normal Unix build cycle. It is disabled by default, but is silently
reenabled if the user configures the source tree via Makefile.PL.
- October 14, 2003 - C API [joes]
Added apreq_header_attribute() and fixed mfd parser to allow
"charset" attribute to appear in the Content-Type header. Sven
Geisler points out that Opera 7.20 does generate such headers.
- October 14, 2003 - C API [joes]
Added versioning API following http://apr.apache.org/versioning.html
apreq_env renamed apreq_env_name, and apreq_env_magic_number added
to provide versioning for environments (modules). The header files
are now installed to "include/apreq2", and the library is renamed
"libapreq2". Also added an apreq2-config script based on apu-config.
- October 8, 2003 - configure: static mod_apreq.c [Bojan Smojver, joes]
Add --with-apache2-src configure option, along with --with-apr-config
and --with-apu-config, and provide support for compiling mod_apreq
into httpd as a static apache module.
- October 1, 2003 - C API: mod_apreq.c [joes]
Support for internal redirects added to the mod_apreq filter.
This ensures any POST data prefetched in the main request
gets passed along to the subrequest handler(s).
- July 18, 2003 - C bugfix: apreq_decode [Graham Clark]
If the source and destination strings are represented by the same
pointer - e.g. if called as apreq_unescape(s) - string s is modified
incorrectly in general. Patch includes new unit test.
- July 16, 2003 - Perl API [joes]
Added $req->parse, $req->status, & "preparse" logic
to $req->param & $req->upload.
- July 16, 2003 - C API [joes]
Added "preparse" logic to apreq_params & apreq_uploads
to bring behavior in line with libapreq-1.x.
- July 15, 2003 - C API [joes]
Dropped param->charset.
Make apreq_brigade_concat public, so mod_apreq can use it
for its ctx->spool brigade.
- July 14, 2003 - Documentation [joes]
Updated Cookie_pod to reflect API changes over v1.X.
- June 30, 2003 - Documentation [joes]
Added doxygen links to Apache::Request and Apache::Cookie
perl docs.
- June 30, 2003 - C API [joes]
Added apreq_copy_brigade(bb) to apreq.h.
- June 27, 2003 - C API [joes]
The new filter-based design required a complete
departure from libapreq-1.X codebase. libapreq-2
is based solely on APR, and to be fully functional,
requires a supporting environment similar to Apache-2.
A person wishing to port libapreq-2 to a new environment
needs to provide definitions for the declarations in apreq_env.h.
- June 27, 2003 - Perl API [joes]
Aggregates are always collected into an APR::Table-based package.
New table packages: Apache::Cookie::Table, Apache::Request::Table,
and Apache::Upload::Table.
- June 27, 2003 - Perl API [joes]
Apache::Cookie->fetch now requires an "environment" argument ($r).
Its return value is blessed into the Apache::Cookie::Jar class.
- June 27, 2003 - Perl API [joes]
Two new request lookup functions:
-# $req->args - param lookup using only the query string
-# $req->body - param lookup using only the POST data
--
Joe Schaefer
Re: [ANNOUNCE] libapreq2-2.01_03-dev released
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
>
>>Joe Schaefer wrote:
>>
>>
>>>CURRENT RELEASE NOTES:
>>> - This is a developer release, indicated by the "-dev" suffix
>>> on the version string. We believe the core interfaces to be stable,
>>> but some portions of the API may still need significant modification.
>>> Thus, binary/source compatibility may be broken from one developer
>>>release to the next. In particular the version numbering rules specified
>>> at
>>
>>Joe, are you sure you are not artificially building acceptance walls?
>>You are talking about C API in the post to the mod_perl list. Most
>>people won't even try it, because of that.
>
>
> "Most people" shouldn't try it- developers should. It's their feedback
> that determines what we most need to change. At this point, perl users
> need to be looking to *the test suite* for the stable components of the
> API, not *the documentation*. Until that situation changes, I see no
> harm in scaring off the faint of heart.
Those developers are "most people", they won't try it in their code if you say
that the perl API is not stable. I guess I'm talking mostly about those
developers who wait in anxiety for the Apache::Request 2.0 release so they can
move to mod_perl 2.0. I could be wrong.
>>Or does it really true the perl may still need significant
>>modification?
>
>
> Absolutely. We need to really flesh out the perl glue in CGI
> before we can claim stability, just like we needed to do it for
> the C API.
OK, thanks for the clarification, Joe.
>>I thought it's going to stay pretty close to the apreq1 API.
>
>
> "Pretty close" is what the tests are there for.
>
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [ANNOUNCE] libapreq2-2.01_03-dev released
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Joe Schaefer wrote:
>
> > CURRENT RELEASE NOTES:
> > - This is a developer release, indicated by the "-dev" suffix
> > on the version string. We believe the core interfaces to be stable,
> > but some portions of the API may still need significant modification.
> > Thus, binary/source compatibility may be broken from one developer
> > release to the next. In particular the version numbering rules specified
> > at
>
> Joe, are you sure you are not artificially building acceptance walls?
> You are talking about C API in the post to the mod_perl list. Most
> people won't even try it, because of that.
"Most people" shouldn't try it- developers should. It's their feedback
that determines what we most need to change. At this point, perl users
need to be looking to *the test suite* for the stable components of the
API, not *the documentation*. Until that situation changes, I see no
harm in scaring off the faint of heart.
> Or does it really true the perl may still need significant
> modification?
Absolutely. We need to really flesh out the perl glue in CGI
before we can claim stability, just like we needed to do it for
the C API.
> I thought it's going to stay pretty close to the apreq1 API.
"Pretty close" is what the tests are there for.
--
Joe Schaefer
Re: [ANNOUNCE] libapreq2-2.01_03-dev released
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> The uploaded file
>
> libapreq2-2.01_03-dev.tar.gz
>
> has entered CPAN as
>
> file: $CPAN/authors/id/J/JO/JOESUF/libapreq2-2.01_03-dev.tar.gz
> size: 458218 bytes
> md5: 736b4da910a221d05479a69b1e18e02d
>
>
> CURRENT RELEASE NOTES:
>
> - This is a developer release, indicated by the "-dev" suffix
> on the version string. We believe the core interfaces to be stable,
> but some portions of the API may still need significant modification.
> Thus, binary/source compatibility may be broken from one developer
> release to the next. In particular the version numbering rules specified
> at
Joe, are you sure you are not artificially building acceptance walls? You are
talking about C API in the post to the mod_perl list. Most people won't even
try it, because of that. Or does it really true the perl may still need
significant modification? I thought it's going to stay pretty close to the
apreq1 API.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com