You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by mi...@apache.org on 2010/02/14 16:09:57 UTC
svn commit: r910017 - in /httpd/httpd/trunk: CHANGES docs/manual/filter.xml
docs/manual/mod/allmodules.xml docs/manual/mod/mod_reflector.xml
modules/filters/config.m4 modules/filters/mod_reflector.c
Author: minfrin
Date: Sun Feb 14 15:09:53 2010
New Revision: 910017
URL: http://svn.apache.org/viewvc?rev=910017&view=rev
Log:
Introduce mod_reflector, a handler capable of reflecting POSTed
request bodies back within the response through the output filter
stack. Can be used to turn an output filter into a web service.
Added:
httpd/httpd/trunk/docs/manual/mod/mod_reflector.xml
httpd/httpd/trunk/modules/filters/mod_reflector.c
Modified:
httpd/httpd/trunk/CHANGES
httpd/httpd/trunk/docs/manual/filter.xml
httpd/httpd/trunk/docs/manual/mod/allmodules.xml
httpd/httpd/trunk/modules/filters/config.m4
Modified: httpd/httpd/trunk/CHANGES
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=910017&r1=910016&r2=910017&view=diff
==============================================================================
--- httpd/httpd/trunk/CHANGES [utf-8] (original)
+++ httpd/httpd/trunk/CHANGES [utf-8] Sun Feb 14 15:09:53 2010
@@ -2,6 +2,11 @@
Changes with Apache 2.3.7
+ *) Introduce mod_reflector, a handler capable of reflecting POSTed
+ request bodies back within the response through the output filter
+ stack. Can be used to turn an output filter into a web service.
+ [Graham Leggett]
+
*) mod_proxy_http: Make sure that when an ErrorDocument is served
from a reverse proxied URL, that the subrequest respects the status
of the original request. This brings the behaviour of proxy_handler
Modified: httpd/httpd/trunk/docs/manual/filter.xml
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/filter.xml?rev=910017&r1=910016&r2=910017&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/filter.xml (original)
+++ httpd/httpd/trunk/docs/manual/filter.xml Sun Feb 14 15:09:53 2010
@@ -37,6 +37,7 @@
<module>mod_ext_filter</module>
<module>mod_include</module>
<module>mod_charset_lite</module>
+ <module>mod_reflector</module>
</modulelist>
<directivelist>
<directive module="mod_filter">FilterChain</directive>
@@ -47,6 +48,7 @@
<directive module="mod_mime">AddOutputFilter</directive>
<directive module="mod_mime">RemoveInputFilter</directive>
<directive module="mod_mime">RemoveOutputFilter</directive>
+ <directive module="mod_reflector">ReflectorHeader</directive>
<directive module="mod_ext_filter">ExtFilterDefine</directive>
<directive module="mod_ext_filter">ExtFilterOptions</directive>
<directive module="core">SetInputFilter</directive>
@@ -118,6 +120,25 @@
</ul>
</section>
+<section id="service">
+
+<title>Exposing Filters as an HTTP Service</title>
+<p>Filters can be used to process content originating from the client in
+addition to processing content originating on the server using the
+<module>mod_reflector</module> module.</p>
+
+<p><module>mod_reflector</module> accepts POST requests from clients, and reflects
+the content request body received within the POST request back in the response,
+passing through the output filter stack on the way back to the client.</p>
+
+<p>This technique can be used as an alternative to a web service running within
+an application server stack, where an output filter provides the transformation
+required on the request body. For example, the <module>mod_deflate</module>
+module might be used to provide a general compression service, or an image
+transformation filter might be turned into an image transformation service.</p>
+
+</section>
+
<section id="using">
<title>Using Filters</title>
<p>There are two ways to use filtering: Simple and Dynamic.
Modified: httpd/httpd/trunk/docs/manual/mod/allmodules.xml
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/allmodules.xml?rev=910017&r1=910016&r2=910017&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/allmodules.xml (original)
+++ httpd/httpd/trunk/docs/manual/mod/allmodules.xml Sun Feb 14 15:09:53 2010
@@ -75,6 +75,7 @@
<modulefile>mod_proxy_ftp.xml</modulefile>
<modulefile>mod_proxy_http.xml</modulefile>
<modulefile>mod_proxy_scgi.xml</modulefile>
+ <modulefile>mod_reflector.xml</modulefile>
<modulefile>mod_remoteip.xml</modulefile>
<modulefile>mod_reqtimeout.xml</modulefile>
<modulefile>mod_request.xml</modulefile>
Added: httpd/httpd/trunk/docs/manual/mod/mod_reflector.xml
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_reflector.xml?rev=910017&view=auto
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_reflector.xml (added)
+++ httpd/httpd/trunk/docs/manual/mod/mod_reflector.xml Sun Feb 14 15:09:53 2010
@@ -0,0 +1,83 @@
+<?xml version="1.0"?>
+<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
+<?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
+<!-- $LastChangedRevision: 894290 $ -->
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<modulesynopsis metafile="mod_reflector.xml.meta">
+
+<name>mod_reflector</name>
+<description>Reflect a request body as a response via the output filter stack.</description>
+<status>Base</status>
+<sourcefile>mod_reflector.c</sourcefile>
+<identifier>reflector_module</identifier>
+<compatibility>Version 2.3 and later</compatibility>
+
+<summary>
+ <p>This module allows request bodies to be reflected back to the
+ client, in the process passing the request through the output filter
+ stack. A suitably configured chain of filters can be used to transform
+ the request into a response. This module can used to turn an output
+ filter into an HTTP service.</p>
+</summary>
+
+<section id="examples"><title>Examples</title>
+ <dl>
+ <dt>Compression service</dt>
+ <dd>Pass the request body through the DEFLATE filter to compress the
+ body. This request requires a Content-Encoding request header containing
+ "gzip" for the filter to return compressed data.
+ <example>
+ <Location /compress><br/>
+ SetHandler reflector<br/>
+ SetOutputFilter DEFLATE<br/>
+ </Location>
+ </example>
+ </dd>
+
+ <dt>Image downsampling service</dt>
+ <dd>Pass the request body through an image downsampling filter, and reflect
+ the results to the caller.
+ <example>
+ <Location /downsample><br/>
+ SetHandler reflector<br/>
+ SetOutputFilter DOWNSAMPLE<br/>
+ </Location>
+ </example>
+ </dd>
+ </dl>
+</section>
+
+<directivesynopsis>
+<name>ReflectorHeader</name>
+<description>Reflect an input header to the output headers</description>
+<syntax>ReflectorHeader <var>inputheader</var> <var>[outputheader]</var></syntax>
+<contextlist><context>server config</context><context>virtual host</context>
+<context>directory</context><context>.htaccess</context></contextlist>
+<override>Options</override>
+
+<usage>
+ <p>This directive controls the reflection of request headers to the response.
+ The first argument is the name of the request header to copy. If the optional
+ second argument is specified, it will be used as the name of the response
+ header, otherwise the original request header name will be used.</p>
+</usage>
+</directivesynopsis>
+
+</modulesynopsis>
Modified: httpd/httpd/trunk/modules/filters/config.m4
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/filters/config.m4?rev=910017&r1=910016&r2=910017&view=diff
==============================================================================
--- httpd/httpd/trunk/modules/filters/config.m4 (original)
+++ httpd/httpd/trunk/modules/filters/config.m4 Sun Feb 14 15:09:53 2010
@@ -11,6 +11,7 @@
APACHE_MODULE(request, Request Body Filtering, , , yes)
APACHE_MODULE(include, Server Side Includes, , , yes)
APACHE_MODULE(filter, Smart Filtering, , , yes)
+APACHE_MODULE(reflector, Reflect request through the output filter stack, , , yes)
APACHE_MODULE(substitute, response content rewrite-like filtering, , , most)
sed_obj="mod_sed.lo sed0.lo sed1.lo regexp.lo"
Added: httpd/httpd/trunk/modules/filters/mod_reflector.c
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/filters/mod_reflector.c?rev=910017&view=auto
==============================================================================
--- httpd/httpd/trunk/modules/filters/mod_reflector.c (added)
+++ httpd/httpd/trunk/modules/filters/mod_reflector.c Sun Feb 14 15:09:53 2010
@@ -0,0 +1,231 @@
+/* Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include "apr_tables.h"
+
+#include "httpd.h"
+#include "http_config.h"
+#include "http_core.h"
+#include "http_log.h"
+#include "http_request.h"
+
+module AP_MODULE_DECLARE_DATA reflector_module;
+
+typedef struct {
+ apr_table_t *headers;
+} reflector_cfg;
+
+static int header_do(void *dummy, const char *key, const char *value)
+{
+ request_rec *r = (request_rec *) dummy;
+ const char *payload;
+
+ payload = apr_table_get(r->headers_in, key);
+ if (payload) {
+ apr_table_setn(r->headers_out, value, payload);
+ }
+
+ return 1;
+}
+
+static int reflector_handler(request_rec * r)
+{
+ apr_bucket_brigade *bbin, *bbout;
+ apr_bucket *e;
+ reflector_cfg *conf;
+ apr_status_t status;
+
+ if (strcmp(r->handler, "reflector")) {
+ return DECLINED;
+ }
+
+ conf = (reflector_cfg *) ap_get_module_config(r->per_dir_config,
+ &reflector_module);
+
+ ap_allow_methods(r, 1, "POST", "OPTIONS", NULL);
+
+ if (r->method_number == M_OPTIONS) {
+ return ap_send_http_options(r);
+ }
+
+ else if (r->method_number == M_POST) {
+ const char *content_length, *content_type;
+ int seen_eos;
+
+ /*
+ * Sometimes we'll get in a state where the input handling has
+ * detected an error where we want to drop the connection, so if
+ * that's the case, don't read the data as that is what we're trying
+ * to avoid.
+ *
+ * This function is also a no-op on a subrequest.
+ */
+ if (r->main || r->connection->keepalive == AP_CONN_CLOSE ||
+ ap_status_drops_connection(r->status)) {
+ return OK;
+ }
+
+ /* copy headers from in to out if configured */
+ apr_table_do(header_do, r, conf->headers, NULL);
+
+ /* last modified defaults to now, unless otherwise set on the way in */
+ if (!apr_table_get(r->headers_out, "Last-Modified")) {
+ ap_update_mtime(r, apr_time_now());
+ ap_set_last_modified(r);
+ }
+ apr_table_setn(r->headers_out, "Accept-Ranges", "bytes");
+
+ /* reflect the content length, if present */
+ if ((content_length = apr_table_get(r->headers_in, "Content-Length"))) {
+ apr_off_t offset;
+
+ apr_strtoff(&offset, content_length, NULL, 10);
+ ap_set_content_length(r, offset);
+
+ }
+
+ /* reflect the content type, if present */
+ if ((content_type = apr_table_get(r->headers_in, "Content-Type"))) {
+
+ ap_set_content_type(r, content_type);
+
+ }
+
+ bbin = apr_brigade_create(r->pool, r->connection->bucket_alloc);
+ bbout = apr_brigade_create(r->pool, r->connection->bucket_alloc);
+
+ seen_eos = 0;
+ do {
+ apr_bucket *bucket;
+
+ status = ap_get_brigade(r->input_filters, bbin, AP_MODE_READBYTES,
+ APR_BLOCK_READ, HUGE_STRING_LEN);
+
+ if (status != APR_SUCCESS) {
+ if (status == AP_FILTER_ERROR) {
+ apr_brigade_destroy(bbin);
+ return status;
+ }
+ else {
+ apr_brigade_destroy(bbin);
+ return HTTP_BAD_REQUEST;
+ }
+ }
+
+ for (bucket = APR_BRIGADE_FIRST(bbin);
+ bucket != APR_BRIGADE_SENTINEL(bbin);
+ bucket = APR_BUCKET_NEXT(bucket)) {
+ const char *data;
+ apr_size_t len;
+
+ if (APR_BUCKET_IS_EOS(bucket)) {
+ seen_eos = 1;
+ break;
+ }
+
+ /* These are metadata buckets. */
+ if (bucket->length == 0) {
+ continue;
+ }
+
+ /*
+ * We MUST read because in case we have an unknown-length
+ * bucket or one that morphs, we want to exhaust it.
+ */
+ status = apr_bucket_read(bucket, &data, &len, APR_BLOCK_READ);
+ if (status != APR_SUCCESS) {
+ apr_brigade_destroy(bbin);
+ return HTTP_BAD_REQUEST;
+ }
+
+ apr_brigade_write(bbout, NULL, NULL, data, len);
+
+ status = ap_pass_brigade(r->output_filters, bbout);
+ if (status != APR_SUCCESS) {
+ /* no way to know what type of error occurred */
+ ap_log_rerror(APLOG_MARK, APLOG_DEBUG, status, r,
+ "default_handler: ap_pass_brigade returned %i",
+ status);
+ return HTTP_INTERNAL_SERVER_ERROR;
+ }
+
+ }
+
+ apr_brigade_cleanup(bbin);
+
+ } while (!seen_eos);
+
+ return OK;
+
+ }
+
+ else {
+ return HTTP_METHOD_NOT_ALLOWED;
+ }
+
+}
+
+static void *create_reflector_dir_config(apr_pool_t * p, char *d)
+{
+ reflector_cfg *conf = apr_pcalloc(p, sizeof(reflector_cfg));
+
+ conf->headers = apr_table_make(p, 8);
+
+ return conf;
+}
+
+static void *merge_reflector_dir_config(apr_pool_t * p, void *basev, void *addv)
+{
+ reflector_cfg *new = (reflector_cfg *) apr_pcalloc(p,
+ sizeof(reflector_cfg));
+ reflector_cfg *add = (reflector_cfg *) addv;
+ reflector_cfg *base = (reflector_cfg *) basev;
+
+ new->headers = apr_table_overlay(p, add->headers, base->headers);
+
+ return new;
+}
+
+static const char *reflector_header(cmd_parms * cmd, void *dummy, const char *in,
+ const char *out)
+{
+ reflector_cfg *cfg = (reflector_cfg *) dummy;
+
+ apr_table_addn(cfg->headers, in, out ? out : in);
+
+ return NULL;
+}
+
+static void reflector_hooks(apr_pool_t * p)
+{
+ ap_hook_handler(reflector_handler, NULL, NULL, APR_HOOK_MIDDLE);
+}
+
+static const command_rec reflector_cmds[] = {
+ AP_INIT_TAKE12("ReflectorHeader", reflector_header, NULL, OR_OPTIONS,
+ "Header to reflect back in the response, with an optional new name."),
+ {NULL}
+};
+
+module AP_MODULE_DECLARE_DATA reflector_module = {
+ STANDARD20_MODULE_STUFF,
+ create_reflector_dir_config,
+ merge_reflector_dir_config,
+ NULL,
+ NULL,
+ reflector_cmds,
+ reflector_hooks
+};
Re: svn commit: r910017 - in /httpd/httpd/trunk: CHANGES docs/manual/filter.xml docs/manual/mod/allmodules.xml docs/manual/mod/mod_reflector.xml modules/filters/config.m4 modules/filters/mod_reflector.c
Posted by Graham Leggett <mi...@sharp.fm>.
On 14 Feb 2010, at 6:55 PM, Ruediger Pluem wrote:
> + /*
>>
>> + * We MUST read because in case we have an unknown-
>> length
>> + * bucket or one that morphs, we want to exhaust it.
>> + */
>> + status = apr_bucket_read(bucket, &data, &len,
>> APR_BLOCK_READ);
>
> Can't we check first if this bucket is of unknown length and only
> read if it is?
> Otherwise we could move it just over to the output brigade, correct?
I tried that and it didn't work for me. Without the apr_bucket_read(),
no EOS bucket is ever generated, and the loop spins.
Regards,
Graham
--
Re: svn commit: r910017 - in /httpd/httpd/trunk: CHANGES docs/manual/filter.xml
docs/manual/mod/allmodules.xml docs/manual/mod/mod_reflector.xml modules/filters/config.m4
modules/filters/mod_reflector.c
Posted by Ruediger Pluem <rp...@apache.org>.
On 14.02.2010 16:09, minfrin@apache.org wrote:
> Author: minfrin
> Date: Sun Feb 14 15:09:53 2010
> New Revision: 910017
>
> URL: http://svn.apache.org/viewvc?rev=910017&view=rev
> Log:
> Introduce mod_reflector, a handler capable of reflecting POSTed
> request bodies back within the response through the output filter
> stack. Can be used to turn an output filter into a web service.
>
> Added:
> httpd/httpd/trunk/docs/manual/mod/mod_reflector.xml
> httpd/httpd/trunk/modules/filters/mod_reflector.c
> Modified:
> httpd/httpd/trunk/CHANGES
> httpd/httpd/trunk/docs/manual/filter.xml
> httpd/httpd/trunk/docs/manual/mod/allmodules.xml
> httpd/httpd/trunk/modules/filters/config.m4
>
> Added: httpd/httpd/trunk/modules/filters/mod_reflector.c
> URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/filters/mod_reflector.c?rev=910017&view=auto
> ==============================================================================
> --- httpd/httpd/trunk/modules/filters/mod_reflector.c (added)
> +++ httpd/httpd/trunk/modules/filters/mod_reflector.c Sun Feb 14 15:09:53 2010
> @@ -0,0 +1,231 @@
> +static int reflector_handler(request_rec * r)
> +{
> + apr_bucket_brigade *bbin, *bbout;
> + apr_bucket *e;
> + reflector_cfg *conf;
> + apr_status_t status;
> +
> + if (strcmp(r->handler, "reflector")) {
> + return DECLINED;
> + }
> +
> + conf = (reflector_cfg *) ap_get_module_config(r->per_dir_config,
> + &reflector_module);
> +
> + ap_allow_methods(r, 1, "POST", "OPTIONS", NULL);
> +
> + if (r->method_number == M_OPTIONS) {
> + return ap_send_http_options(r);
> + }
> +
> + else if (r->method_number == M_POST) {
> + const char *content_length, *content_type;
> + int seen_eos;
> +
> + /*
> + * Sometimes we'll get in a state where the input handling has
> + * detected an error where we want to drop the connection, so if
> + * that's the case, don't read the data as that is what we're trying
> + * to avoid.
> + *
> + * This function is also a no-op on a subrequest.
> + */
> + if (r->main || r->connection->keepalive == AP_CONN_CLOSE ||
> + ap_status_drops_connection(r->status)) {
> + return OK;
> + }
> +
> + /* copy headers from in to out if configured */
> + apr_table_do(header_do, r, conf->headers, NULL);
> +
> + /* last modified defaults to now, unless otherwise set on the way in */
> + if (!apr_table_get(r->headers_out, "Last-Modified")) {
> + ap_update_mtime(r, apr_time_now());
> + ap_set_last_modified(r);
> + }
> + apr_table_setn(r->headers_out, "Accept-Ranges", "bytes");
> +
> + /* reflect the content length, if present */
> + if ((content_length = apr_table_get(r->headers_in, "Content-Length"))) {
> + apr_off_t offset;
> +
> + apr_strtoff(&offset, content_length, NULL, 10);
> + ap_set_content_length(r, offset);
> +
> + }
> +
> + /* reflect the content type, if present */
> + if ((content_type = apr_table_get(r->headers_in, "Content-Type"))) {
> +
> + ap_set_content_type(r, content_type);
> +
> + }
> +
> + bbin = apr_brigade_create(r->pool, r->connection->bucket_alloc);
> + bbout = apr_brigade_create(r->pool, r->connection->bucket_alloc);
> +
> + seen_eos = 0;
> + do {
> + apr_bucket *bucket;
> +
> + status = ap_get_brigade(r->input_filters, bbin, AP_MODE_READBYTES,
> + APR_BLOCK_READ, HUGE_STRING_LEN);
> +
> + if (status != APR_SUCCESS) {
> + if (status == AP_FILTER_ERROR) {
> + apr_brigade_destroy(bbin);
> + return status;
> + }
> + else {
> + apr_brigade_destroy(bbin);
> + return HTTP_BAD_REQUEST;
> + }
> + }
> +
> + for (bucket = APR_BRIGADE_FIRST(bbin);
> + bucket != APR_BRIGADE_SENTINEL(bbin);
> + bucket = APR_BUCKET_NEXT(bucket)) {
> + const char *data;
> + apr_size_t len;
> +
> + if (APR_BUCKET_IS_EOS(bucket)) {
> + seen_eos = 1;
> + break;
> + }
> +
> + /* These are metadata buckets. */
> + if (bucket->length == 0) {
> + continue;
> + }
> +
> + /*
> + * We MUST read because in case we have an unknown-length
> + * bucket or one that morphs, we want to exhaust it.
> + */
> + status = apr_bucket_read(bucket, &data, &len, APR_BLOCK_READ);
Can't we check first if this bucket is of unknown length and only read if it is?
Otherwise we could move it just over to the output brigade, correct?
> + if (status != APR_SUCCESS) {
> + apr_brigade_destroy(bbin);
> + return HTTP_BAD_REQUEST;
> + }
> +
> + apr_brigade_write(bbout, NULL, NULL, data, len);
> +
> + status = ap_pass_brigade(r->output_filters, bbout);
> + if (status != APR_SUCCESS) {
> + /* no way to know what type of error occurred */
> + ap_log_rerror(APLOG_MARK, APLOG_DEBUG, status, r,
> + "default_handler: ap_pass_brigade returned %i",
This not the default handler.
> + status);
> + return HTTP_INTERNAL_SERVER_ERROR;
> + }
> +
> + }
> +
> + apr_brigade_cleanup(bbin);
> +
> + } while (!seen_eos);
> +
> + return OK;
> +
> + }
> +
> + else {
> + return HTTP_METHOD_NOT_ALLOWED;
> + }
> +
> +}
Regards
Rüdiger
Re: svn commit: r910017 - in /httpd/httpd/trunk: CHANGES docs/manual/filter.xml
docs/manual/mod/allmodules.xml docs/manual/mod/mod_reflector.xml modules/filters/config.m4
modules/filters/mod_reflector.c
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 2/15/2010 4:08 PM, Graham Leggett wrote:
> On 15 Feb 2010, at 11:38 PM, Nick Kew wrote:
>
>> I think the point was, all the above happened after you'd committed.
>> Maybe it would've been a good idea to discuss it first?
>
> To me, no, but not because I disagree with you, but rather because every
> time we make a commit we make a call: is this small enough to warrant
> commit-then-review, or is it big enough to warrant review-then-commit?
Something of the granularity of an entire *module* is certainly not 'small'
at this project. In fact, after I took on chair of this project, I still
proposed the small mod_remoteip for inclusion before I committed it to the
httpd trunk. Small? Check. Simple? Check.
But committing the project to maintaining a module after your code dump is
no small matter; please ask first :)
Re: svn commit: r910017 - in /httpd/httpd/trunk: CHANGES docs/manual/filter.xml docs/manual/mod/allmodules.xml docs/manual/mod/mod_reflector.xml modules/filters/config.m4 modules/filters/mod_reflector.c
Posted by Graham Leggett <mi...@sharp.fm>.
On 15 Feb 2010, at 11:38 PM, Nick Kew wrote:
> I think the point was, all the above happened after you'd committed.
> Maybe it would've been a good idea to discuss it first?
To me, no, but not because I disagree with you, but rather because
every time we make a commit we make a call: is this small enough to
warrant commit-then-review, or is it big enough to warrant review-then-
commit? Sometimes, it is borderline, and I made the call this time
round to commit-then-review.
How big does a patch need to be before needing mention in the docs?
Which changes are major enough to justify an entry in CHANGES and
which are minor enough not to matter? What constitutes a bugfix, and
what constitutes a new feature? Sometimes these are clear, but
sometimes these are not, and people will not always agree. And when
people don't agree, being tactful and diplomatic goes a long way.
Regards,
Graham
--
Re: svn commit: r910017 - in /httpd/httpd/trunk: CHANGES
docs/manual/filter.xml docs/manual/mod/allmodules.xml
docs/manual/mod/mod_reflector.xml modules/filters/config.m4
modules/filters/mod_reflector.c
Posted by Nick Kew <ni...@webthing.com>.
Graham Leggett wrote:
> On 15 Feb 2010, at 3:40 PM, Jeff Trawick wrote:
>
>>> Can you speak up and explain why it shouldn't?
>>
>> AFAICT you're the only one in the world that cares about it (whether
>> or not that is true; there's been no discussion).
>
> Did you not see rpluem's response and my response to it? Did you not see
> fuankg's addition to the Netware build? I count two people so far who
> cared enough to contribute, and that's just in the last 24 hours. Why
> did you not join these discussions?
I think the point was, all the above happened after you'd committed.
Maybe it would've been a good idea to discuss it first?
Even including the above, that's only the mechanics of it people
have looked at. The first post here (other than yours) discussing
the merits of it was mine of a few minutes ago.
--
Nick Kew
Re: svn commit: r910017 - in /httpd/httpd/trunk: CHANGES docs/manual/filter.xml
docs/manual/mod/allmodules.xml docs/manual/mod/mod_reflector.xml modules/filters/config.m4
modules/filters/mod_reflector.c
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 2/15/2010 3:35 PM, Jeff Trawick wrote:
>
> I saw that. I did not equate that to an indication that those
> individuals had reflected on the module and agreed that it belonged in
> the base distribution.
+1; when I facilitate win32 builds, I am not suggesting that the code even
functions, never mind the value of including that code in the project.
I'm simply getting it to build.
Re: svn commit: r910017 - in /httpd/httpd/trunk: CHANGES
docs/manual/filter.xml docs/manual/mod/allmodules.xml docs/manual/mod/mod_reflector.xml
modules/filters/config.m4 modules/filters/mod_reflector.c
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, Feb 15, 2010 at 4:14 PM, Graham Leggett <mi...@sharp.fm> wrote:
> On 15 Feb 2010, at 3:40 PM, Jeff Trawick wrote:
>
>>> Can you speak up and explain why it shouldn't?
>>
>> AFAICT you're the only one in the world that cares about it (whether
>> or not that is true; there's been no discussion).
>
> Did you not see rpluem's response and my response to it? Did you not see
> fuankg's addition to the Netware build? I count two people so far who cared
> enough to contribute, and that's just in the last 24 hours. Why did you not
> join these discussions?
I saw that. I did not equate that to an indication that those
individuals had reflected on the module and agreed that it belonged in
the base distribution.
>
> There is no greater disincentive to working on the httpd project than this
> kind of response. Making it worse, instead of making a case yourself, you
> simply solicit others to make your case for you. When a potential
> contributor reads this thread and others like it, all they see is that their
> contribution is not welcome here, they quietly unsubscribe and the httpd
> project suffers as a result.
The nature of my interest is to find out if multiple developers are
interested in this module being part of the base distribution. Yes,
that involves soliciting others. (Whether I asked them to make a case
for the module or against it is another question.)
>
>> All I really care is that multiple developers think it is a good idea
>> to include it in the base distribution. (If not, then I don't think
>> it should be here.)
>
> I am confident that if multiple developers believe it shouldn't be, then
> those multiple developers will speak for themselves. It is in extremely poor
> taste to actively try to solicit developers to speak out against somebody's
> contribution. Let the community speak for itself.
We're talking about two different things. Finding a couple of other
people that think inclusion is a good idea (EXTREMELY LOW BARRIER TO
ENTRY) is much different than finding a couple of other people that
think inclusion is not a good idea or otherwise will speak out against
it (EXTREMELY HIGH BARRIER TO ENTRY).
Re: svn commit: r910017 - in /httpd/httpd/trunk: CHANGES docs/manual/filter.xml docs/manual/mod/allmodules.xml docs/manual/mod/mod_reflector.xml modules/filters/config.m4 modules/filters/mod_reflector.c
Posted by Graham Leggett <mi...@sharp.fm>.
On 15 Feb 2010, at 3:40 PM, Jeff Trawick wrote:
>> Can you speak up and explain why it shouldn't?
>
> AFAICT you're the only one in the world that cares about it (whether
> or not that is true; there's been no discussion).
Did you not see rpluem's response and my response to it? Did you not
see fuankg's addition to the Netware build? I count two people so far
who cared enough to contribute, and that's just in the last 24 hours.
Why did you not join these discussions?
There is no greater disincentive to working on the httpd project than
this kind of response. Making it worse, instead of making a case
yourself, you simply solicit others to make your case for you. When a
potential contributor reads this thread and others like it, all they
see is that their contribution is not welcome here, they quietly
unsubscribe and the httpd project suffers as a result.
> All I really care is that multiple developers think it is a good idea
> to include it in the base distribution. (If not, then I don't think
> it should be here.)
I am confident that if multiple developers believe it shouldn't be,
then those multiple developers will speak for themselves. It is in
extremely poor taste to actively try to solicit developers to speak
out against somebody's contribution. Let the community speak for itself.
Regards,
Graham
--
Re: svn commit: r910017 - in /httpd/httpd/trunk: CHANGES docs/manual/filter.xml docs/manual/mod/allmodules.xml docs/manual/mod/mod_reflector.xml modules/filters/config.m4 modules/filters/mod_reflector.c
Posted by Graham Leggett <mi...@sharp.fm>.
On 15 Feb 2010, at 11:33 PM, Nick Kew wrote:
> Whether that merits it going in the trunk is another question.
> If it does, then surely /filters/ is the wrong place: it's
> a generator!
I angsted about that. It's purpose is to reflect to the filter stack,
and so I chose /filters, but it is technically a generator as you
point out.
Do the /filters and /generators directories indicate their purpose or
their implementation? I don't mind which.
Regards,
Graham
--
Re: svn commit: r910017 - in /httpd/httpd/trunk: CHANGES
docs/manual/filter.xml docs/manual/mod/allmodules.xml
docs/manual/mod/mod_reflector.xml modules/filters/config.m4
modules/filters/mod_reflector.c
Posted by Nick Kew <ni...@webthing.com>.
Jeff Trawick wrote:
>> On that basis, together with the fact that it's small and
>> documented, I'll give it a +1.
>
> Thanks Nick; that's exactly the kind of feedback I think we should
> look for prior to adding yet another module.
Indeed, that's how I read Rüdiger's post I was following up to
and (in case it wasn't clear) agreeing with.
> (BTW, I assume your "+1" is for including in trunk vs. "sandbox" or
> elsewhere, though that wasn't abundantly clear.)
That was deliberately unclear. I just wanted to express a moderate
level of support-in-principle, and see if anyone else would be
drawn into a discussion of the merits.
But since you ask, I'll give a tentative reply and say trunk.
Unlike some of the other new (post-2.2) modules in trunk,
it's small and simple enough that sandboxing would seem
probably OTT.
--
Nick Kew
Re: svn commit: r910017 - in /httpd/httpd/trunk: CHANGES
docs/manual/filter.xml docs/manual/mod/allmodules.xml docs/manual/mod/mod_reflector.xml
modules/filters/config.m4 modules/filters/mod_reflector.c
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, Feb 15, 2010 at 4:33 PM, Nick Kew <ni...@webthing.com> wrote:
> Ruediger Pluem wrote:
>
>> We should ensure that there is enough interest and support in new modules
>> before we add them to the base server. Otherwise we should have something
>> like a modules sandbox. Of course we need to take care that it does not
>> become a dumping ground.
>
> Makes sense.
>
> I'll stick my hand up and say this module is something I'd have
> an interest in: indeed I've hacked similar things for the
> testbed before now. Combine it with markup processing modules
> from xmlns to xslt/transform, for example, and you have an
> interesting family of apps.
>
> Whether that merits it going in the trunk is another question.
> If it does, then surely /filters/ is the wrong place: it's
> a generator!
>
> On that basis, together with the fact that it's small and
> documented, I'll give it a +1.
Thanks Nick; that's exactly the kind of feedback I think we should
look for prior to adding yet another module.
(BTW, I assume your "+1" is for including in trunk vs. "sandbox" or
elsewhere, though that wasn't abundantly clear.)
Re: svn commit: r910017 - in /httpd/httpd/trunk: CHANGES
docs/manual/filter.xml docs/manual/mod/allmodules.xml
docs/manual/mod/mod_reflector.xml modules/filters/config.m4
modules/filters/mod_reflector.c
Posted by Nick Kew <ni...@webthing.com>.
Ruediger Pluem wrote:
> We should ensure that there is enough interest and support in new modules
> before we add them to the base server. Otherwise we should have something
> like a modules sandbox. Of course we need to take care that it does not
> become a dumping ground.
Makes sense.
I'll stick my hand up and say this module is something I'd have
an interest in: indeed I've hacked similar things for the
testbed before now. Combine it with markup processing modules
from xmlns to xslt/transform, for example, and you have an
interesting family of apps.
Whether that merits it going in the trunk is another question.
If it does, then surely /filters/ is the wrong place: it's
a generator!
On that basis, together with the fact that it's small and
documented, I'll give it a +1.
--
Nick Kew
Re: svn commit: r910017 - in /httpd/httpd/trunk: CHANGES docs/manual/filter.xml
docs/manual/mod/allmodules.xml docs/manual/mod/mod_reflector.xml modules/filters/config.m4
modules/filters/mod_reflector.c
Posted by Ruediger Pluem <rp...@apache.org>.
On 15.02.2010 14:40, Jeff Trawick wrote:
> On Mon, Feb 15, 2010 at 8:02 AM, Graham Leggett <mi...@sharp.fm> wrote:
>> On 15 Feb 2010, at 2:11 PM, Jeff Trawick wrote:
>>
>>> Can somebody besides Graham speak up for why this should be in the
>>> httpd distribution and enabled by default?
>>
>> Can you speak up and explain why it shouldn't?
>
> AFAICT you're the only one in the world that cares about it (whether
> or not that is true; there's been no discussion).
>
> All I really care is that multiple developers think it is a good idea
> to include it in the base distribution. (If not, then I don't think
> it should be here.)
>
> If there's no wider support, I'd participate in exploring another way
> for httpd developers to use the ASF infrastructure to store/maintain
> modules up until the point where they pick up enough interest among
> users or the development community to justify inclusion in the base
> and the group maintenance that implies.
+1
We should ensure that there is enough interest and support in new modules
before we add them to the base server. Otherwise we should have something
like a modules sandbox. Of course we need to take care that it does not
become a dumping ground.
Regards
Rüdiger
Re: svn commit: r910017 - in /httpd/httpd/trunk: CHANGES
docs/manual/filter.xml docs/manual/mod/allmodules.xml docs/manual/mod/mod_reflector.xml
modules/filters/config.m4 modules/filters/mod_reflector.c
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, Feb 15, 2010 at 8:02 AM, Graham Leggett <mi...@sharp.fm> wrote:
> On 15 Feb 2010, at 2:11 PM, Jeff Trawick wrote:
>
>> Can somebody besides Graham speak up for why this should be in the
>> httpd distribution and enabled by default?
>
>
> Can you speak up and explain why it shouldn't?
AFAICT you're the only one in the world that cares about it (whether
or not that is true; there's been no discussion).
All I really care is that multiple developers think it is a good idea
to include it in the base distribution. (If not, then I don't think
it should be here.)
If there's no wider support, I'd participate in exploring another way
for httpd developers to use the ASF infrastructure to store/maintain
modules up until the point where they pick up enough interest among
users or the development community to justify inclusion in the base
and the group maintenance that implies.
The Yardstick
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 2/15/2010 7:02 AM, Graham Leggett wrote:
> On 15 Feb 2010, at 2:11 PM, Jeff Trawick wrote:
>
>> Can somebody besides Graham speak up for why this should be in the
>> httpd distribution and enabled by default?
>
> Can you speak up and explain why it shouldn't?
Because all ASF code requires three champions to keep it alive and to
maintain it, even if not all are 'hackers'. E.g. support from any three
folks, docs@ team or dev@ team doesn't matter, would satisfy folks concern.
Re: svn commit: r910017 - in /httpd/httpd/trunk: CHANGES docs/manual/filter.xml docs/manual/mod/allmodules.xml docs/manual/mod/mod_reflector.xml modules/filters/config.m4 modules/filters/mod_reflector.c
Posted by Graham Leggett <mi...@sharp.fm>.
On 15 Feb 2010, at 2:11 PM, Jeff Trawick wrote:
> Can somebody besides Graham speak up for why this should be in the
> httpd distribution and enabled by default?
Can you speak up and explain why it shouldn't?
Regards,
Graham
--
Re: svn commit: r910017 - in /httpd/httpd/trunk: CHANGES
docs/manual/filter.xml docs/manual/mod/allmodules.xml docs/manual/mod/mod_reflector.xml
modules/filters/config.m4 modules/filters/mod_reflector.c
Posted by Jeff Trawick <tr...@gmail.com>.
On Sun, Feb 14, 2010 at 10:09 AM, <mi...@apache.org> wrote:
> Author: minfrin
> Date: Sun Feb 14 15:09:53 2010
> New Revision: 910017
>
> URL: http://svn.apache.org/viewvc?rev=910017&view=rev
> Log:
> Introduce mod_reflector, a handler capable of reflecting POSTed
> request bodies back within the response through the output filter
> stack. Can be used to turn an output filter into a web service.
Can somebody besides Graham speak up for why this should be in the
httpd distribution and enabled by default?
Re: svn commit: r910017 - in /httpd/httpd/trunk: CHANGES docs/manual/filter.xml docs/manual/mod/allmodules.xml docs/manual/mod/mod_reflector.xml modules/filters/config.m4 modules/filters/mod_reflector.c
Posted by Graham Leggett <mi...@sharp.fm>.
On 15 Feb 2010, at 11:26 PM, Ruediger Pluem wrote:
> This modules produces a lot of compiler warnings:
>
> mod_reflector.c: In function ‘reflector_handler’:
> mod_reflector.c:61: warning: implicit declaration of function
> ‘ap_send_http_opti
> ons
> ’
> mod_reflector.c:87: warning: implicit declaration of function
> ‘ap_set_last_modif
> ied
> ’
> mod_reflector.c:95: warning: implicit declaration of function
> ‘apr_strtoff’
> mod_reflector.c:96: warning: implicit declaration of function
> ‘ap_set_content_le
> ngth
> ’
> mod_reflector.c:103: warning: implicit declaration of function
> ‘ap_set_content_t
> ype
> ’
> mod_reflector.c:47: warning: unused variable ‘e’
Aargh, on MacOSX, -pedantic doesn't include -Wall.
Thanks for the heads up, fixed in r910340.
Regards,
Graham
--
Re: svn commit: r910017 - in /httpd/httpd/trunk: CHANGES docs/manual/filter.xml
docs/manual/mod/allmodules.xml docs/manual/mod/mod_reflector.xml modules/filters/config.m4
modules/filters/mod_reflector.c
Posted by Ruediger Pluem <rp...@apache.org>.
On 14.02.2010 16:09, minfrin@apache.org wrote:
> Author: minfrin
> Date: Sun Feb 14 15:09:53 2010
> New Revision: 910017
>
> URL: http://svn.apache.org/viewvc?rev=910017&view=rev
> Log:
> Introduce mod_reflector, a handler capable of reflecting POSTed
> request bodies back within the response through the output filter
> stack. Can be used to turn an output filter into a web service.
>
> Added:
> httpd/httpd/trunk/docs/manual/mod/mod_reflector.xml
> httpd/httpd/trunk/modules/filters/mod_reflector.c
> Modified:
> httpd/httpd/trunk/CHANGES
> httpd/httpd/trunk/docs/manual/filter.xml
> httpd/httpd/trunk/docs/manual/mod/allmodules.xml
> httpd/httpd/trunk/modules/filters/config.m4
>
This modules produces a lot of compiler warnings:
mod_reflector.c: In function ‘reflector_handler’:
mod_reflector.c:61: warning: implicit declaration of function ‘ap_send_http_opti
ons’
mod_reflector.c:87: warning: implicit declaration of function ‘ap_set_last_modif
ied’
mod_reflector.c:95: warning: implicit declaration of function ‘apr_strtoff’
mod_reflector.c:96: warning: implicit declaration of function ‘ap_set_content_le
ngth’
mod_reflector.c:103: warning: implicit declaration of function ‘ap_set_content_t
ype’
mod_reflector.c:47: warning: unused variable ‘e’
Regards
Rüdiger