You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by co...@apache.org on 2018/04/11 19:11:53 UTC
svn commit: r1828926 - in /httpd/httpd/trunk: CHANGES
docs/manual/mod/mod_proxy.xml include/ap_mmn.h modules/proxy/mod_proxy.c
modules/proxy/mod_proxy.h modules/proxy/mod_proxy_http.c
Author: covener
Date: Wed Apr 11 19:11:52 2018
New Revision: 1828926
URL: http://svn.apache.org/viewvc?rev=1828926&view=rev
Log:
PR62199: add worker parameter ResponseFieldSize to mod_proxy
Submitted By: Hank Ibell
Committed By: covener
Modified:
httpd/httpd/trunk/CHANGES
httpd/httpd/trunk/docs/manual/mod/mod_proxy.xml
httpd/httpd/trunk/include/ap_mmn.h
httpd/httpd/trunk/modules/proxy/mod_proxy.c
httpd/httpd/trunk/modules/proxy/mod_proxy.h
httpd/httpd/trunk/modules/proxy/mod_proxy_http.c
Modified: httpd/httpd/trunk/CHANGES
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1828926&r1=1828925&r2=1828926&view=diff
==============================================================================
--- httpd/httpd/trunk/CHANGES [utf-8] (original)
+++ httpd/httpd/trunk/CHANGES [utf-8] Wed Apr 11 19:11:52 2018
@@ -1,6 +1,10 @@
-*- coding: utf-8 -*-
Changes with Apache 2.5.1
+ *) mod_proxy_http: Add new worker parameter 'responsefieldsize' to
+ allow maximum HTTP response header size to be increased past 8192
+ bytes. PR62199. [Hank Ibell <hwibell gmail.com>]
+
*) core: Preserve the original HTTP request method in the '%<m' LogFormat
when an path-based ErrorDocument is used. PR 62186.
[Micha Lenk <micha lenk.info>]
Modified: httpd/httpd/trunk/docs/manual/mod/mod_proxy.xml
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_proxy.xml?rev=1828926&r1=1828925&r2=1828926&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_proxy.xml (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_proxy.xml Wed Apr 11 19:11:52 2018
@@ -1137,6 +1137,13 @@ ProxyPass "/example" "http://backend.exa
to override the <directive>ProxyIOBufferSize</directive> for a specific worker.
This must be at least 512 or set to 0 for the system default of 8192.
</td></tr>
+ <tr><td>responsefieldsize</td>
+ <td>8192</td>
+ <td>Adjust the size of the proxy response field buffer. The buffer size
+ should be at least the size of the largest expected header size from
+ a proxied response. Setting the value to 0 will use the system
+ default of 8192 bytes.
+ </td></tr>
<tr><td>keepalive</td>
<td>Off</td>
<td><p>This parameter should be used when you have a firewall between your
Modified: httpd/httpd/trunk/include/ap_mmn.h
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/include/ap_mmn.h?rev=1828926&r1=1828925&r2=1828926&view=diff
==============================================================================
--- httpd/httpd/trunk/include/ap_mmn.h (original)
+++ httpd/httpd/trunk/include/ap_mmn.h Wed Apr 11 19:11:52 2018
@@ -570,6 +570,7 @@
* ap_regcomp_default_cflag_by_name
* 20171014.7 (2.5.1-dev) Add AP_CORE_DEFAULT macro
* 20171014.8 (2.5.1-dev) Add CONN_STATE_NUM to enum conn_state_e
+ * 20171014.9 (2.5.1-dev) Add response_field_size to proxy_worker_shared
*/
#define MODULE_MAGIC_COOKIE 0x41503235UL /* "AP25" */
@@ -577,7 +578,7 @@
#ifndef MODULE_MAGIC_NUMBER_MAJOR
#define MODULE_MAGIC_NUMBER_MAJOR 20171014
#endif
-#define MODULE_MAGIC_NUMBER_MINOR 8 /* 0...n */
+#define MODULE_MAGIC_NUMBER_MINOR 9 /* 0...n */
/**
* Determine if the server's current MODULE_MAGIC_NUMBER is at least a
Modified: httpd/httpd/trunk/modules/proxy/mod_proxy.c
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy.c?rev=1828926&r1=1828925&r2=1828926&view=diff
==============================================================================
--- httpd/httpd/trunk/modules/proxy/mod_proxy.c (original)
+++ httpd/httpd/trunk/modules/proxy/mod_proxy.c Wed Apr 11 19:11:52 2018
@@ -329,6 +329,14 @@ static const char *set_worker_param(apr_
(int)sizeof(worker->s->upgrade));
}
}
+ else if (!strcasecmp(key, "responsefieldsize")) {
+ long s = atol(val);
+ if (s < 0) {
+ return "ResponseFieldSize must be greater than 0 bytes, or 0 for system default.";
+ }
+ worker->s->response_field_size = (s ? s : HUGE_STRING_LEN);
+ worker->s->response_field_size_set = 1;
+ }
else {
if (set_worker_hc_param_f) {
return set_worker_hc_param_f(p, s, worker, key, val, NULL);
Modified: httpd/httpd/trunk/modules/proxy/mod_proxy.h
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy.h?rev=1828926&r1=1828925&r2=1828926&view=diff
==============================================================================
--- httpd/httpd/trunk/modules/proxy/mod_proxy.h (original)
+++ httpd/httpd/trunk/modules/proxy/mod_proxy.h Wed Apr 11 19:11:52 2018
@@ -459,6 +459,8 @@ typedef struct {
char secret[PROXY_WORKER_MAX_SECRET_SIZE]; /* authentication secret (e.g. AJP13) */
char upgrade[PROXY_WORKER_MAX_SCHEME_SIZE];/* upgrade protocol used by mod_proxy_wstunnel */
char hostname_ex[PROXY_RFC1035_HOSTNAME_SIZE]; /* RFC1035 compliant version of the remote backend address */
+ apr_size_t response_field_size; /* Size of proxy response buffer in bytes. */
+ unsigned int response_field_size_set:1;
} proxy_worker_shared;
#define ALIGNED_PROXY_WORKER_SHARED_SIZE (APR_ALIGN_DEFAULT(sizeof(proxy_worker_shared)))
Modified: httpd/httpd/trunk/modules/proxy/mod_proxy_http.c
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy_http.c?rev=1828926&r1=1828925&r2=1828926&view=diff
==============================================================================
--- httpd/httpd/trunk/modules/proxy/mod_proxy_http.c (original)
+++ httpd/httpd/trunk/modules/proxy/mod_proxy_http.c Wed Apr 11 19:11:52 2018
@@ -28,6 +28,13 @@ static apr_status_t ap_proxy_http_cleanu
request_rec *r,
proxy_conn_rec *backend);
+static apr_status_t ap_proxygetline(apr_bucket_brigade *bb,
+ char *s,
+ int n,
+ request_rec *r,
+ int fold,
+ int *writen);
+
/*
* Canonicalise http-like URLs.
* scheme is the scheme for the URL
@@ -1096,6 +1103,8 @@ static void ap_proxy_read_headers(reques
void *sconf = r->server->module_config;
proxy_server_conf *psc;
proxy_dir_conf *dconf;
+ apr_status_t rc;
+ apr_bucket_brigade *tmp_bb;
dconf = ap_get_module_config(r->per_dir_config, &proxy_module);
psc = (proxy_server_conf *) ap_get_module_config(sconf, &proxy_module);
@@ -1110,7 +1119,14 @@ static void ap_proxy_read_headers(reques
*/
ap_log_rerror(APLOG_MARK, APLOG_TRACE4, 0, r,
"Headers received from backend:");
- while ((len = ap_getline(buffer, size, rr, 1)) > 0) {
+
+ tmp_bb = apr_brigade_create(r->pool, c->bucket_alloc);
+ while (1) {
+ rc = ap_proxygetline(tmp_bb, buffer, size, rr, 1, &len);
+
+ if (len <= 0)
+ break;
+
ap_log_rerror(APLOG_MARK, APLOG_TRACE4, 0, r, "%s", buffer);
if (!(value = strchr(buffer, ':'))) { /* Find the colon separator */
@@ -1180,12 +1196,24 @@ static void ap_proxy_read_headers(reques
process_proxy_header(r, dconf, buffer, value);
saw_headers = 1;
- /* the header was too long; at the least we should skip extra data */
- if (len >= size - 1) {
+ /* The header could not fit in the provided buffer. */
+ if (rc == APR_ENOSPC) {
+ ap_log_rerror(APLOG_MARK, APLOG_WARNING, rc, r, APLOGNO()
+ "header size is over the limit allowed by ResponseFieldSize (%d bytes). "
+ "Bad response header '%s': '%.*s'...",
+ size, buffer, 80, value);
+
+ /* XXX: We overran the limit we passed to ap_rgetline_core, but if the length
+ * exceeded the limit by a small amount, it may have already been consumed
+ * by apr_brigade_split_line called from the core input filter. If that
+ * happens, this loop will throw away the next full line (header) instead of
+ * the remainder of the current long header.
+ */
while ((len = ap_getline(field, MAX_STRING_LEN, rr, 1))
>= MAX_STRING_LEN - 1) {
/* soak up the extra data */
}
+
if (len == 0) /* time to exit the larger loop as well */
break;
}
@@ -1246,7 +1274,8 @@ int ap_proxy_http_process_response(apr_p
proxy_server_conf *conf, char *server_portstr)
{
conn_rec *c = r->connection;
- char buffer[HUGE_STRING_LEN];
+ char *buffer;
+ char fixed_buffer[HUGE_STRING_LEN];
const char *buf;
char keepchar;
apr_bucket *e;
@@ -1255,6 +1284,7 @@ int ap_proxy_http_process_response(apr_p
int len, backasswards;
int interim_response = 0; /* non-zero whilst interim 1xx responses
* are being read. */
+ apr_size_t response_field_size = 0;
int pread_len = 0;
apr_table_t *save_table;
int backend_broke = 0;
@@ -1279,6 +1309,20 @@ int ap_proxy_http_process_response(apr_p
bb = apr_brigade_create(p, c->bucket_alloc);
pass_bb = apr_brigade_create(p, c->bucket_alloc);
+ /* Only use dynamically sized buffer if user specifies ResponseFieldSize */
+ if(backend->worker->s->response_field_size_set) {
+ response_field_size = backend->worker->s->response_field_size;
+
+ if (response_field_size != HUGE_STRING_LEN)
+ buffer = apr_pcalloc(p, response_field_size);
+ else
+ buffer = fixed_buffer;
+ }
+ else {
+ response_field_size = HUGE_STRING_LEN;
+ buffer = fixed_buffer;
+ }
+
/* Setup for 100-Continue timeout if appropriate */
if (do_100_continue) {
apr_socket_timeout_get(backend->sock, &old_timeout);
@@ -1308,11 +1352,11 @@ int ap_proxy_http_process_response(apr_p
apr_brigade_cleanup(bb);
- rc = ap_proxygetline(backend->tmp_bb, buffer, sizeof(buffer),
+ rc = ap_proxygetline(backend->tmp_bb, buffer, response_field_size,
backend->r, 0, &len);
if (len == 0) {
/* handle one potential stray CRLF */
- rc = ap_proxygetline(backend->tmp_bb, buffer, sizeof(buffer),
+ rc = ap_proxygetline(backend->tmp_bb, buffer, response_field_size,
backend->r, 0, &len);
}
if (len <= 0) {
@@ -1386,7 +1430,7 @@ int ap_proxy_http_process_response(apr_p
/* If not an HTTP/1 message or
* if the status line was > 8192 bytes
*/
- if ((major != 1) || (len >= sizeof(buffer)-1)) {
+ if ((major != 1) || (len >= response_field_size - 1)) {
proxy_run_detach_backend(r, backend);
return ap_proxyerror(r, HTTP_BAD_GATEWAY,
apr_pstrcat(p, "Corrupt status line returned by remote "
@@ -1430,7 +1474,7 @@ int ap_proxy_http_process_response(apr_p
"Set-Cookie", NULL);
/* shove the headers direct into r->headers_out */
- ap_proxy_read_headers(r, backend->r, buffer, sizeof(buffer), origin,
+ ap_proxy_read_headers(r, backend->r, buffer, response_field_size, origin,
&pread_len);
if (r->headers_out == NULL) {
Re: svn commit: r1828926 - in /httpd/httpd/trunk: CHANGES
docs/manual/mod/mod_proxy.xml include/ap_mmn.h modules/proxy/mod_proxy.c
modules/proxy/mod_proxy.h modules/proxy/mod_proxy_http.c
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, Jun 26, 2018 at 8:21 AM, Eric Covener <co...@gmail.com> wrote:
> On Tue, Jun 26, 2018 at 9:02 AM Yann Ylavic <yl...@gmail.com> wrote:
> >
> > On Tue, Jun 26, 2018 at 2:48 PM, Eric Covener <co...@gmail.com> wrote:
> > > On Tue, Jun 26, 2018 at 8:37 AM Yann Ylavic <yl...@gmail.com>
> wrote:
> > >>
> > >> On Mon, Jun 25, 2018 at 10:49 PM, Eric Covener <co...@gmail.com>
> wrote:
> > >> >
> > >> > Bill or Yann, do you remember the specific gotcha with setting aside
> > >> > addl bits and re-using them later?
> > >>
> > >> I've never thought it was an issue (re compat) to add some bit(s) in a
> > >> bitfield if there is a hole, wherever this field is in the struct.
> > >> It doesn't change the size and there is no way for the user to have
> > >> used the address of any bit in the first place (it can't break
> > >> anything IMHO).
> > >> Bill objected to this, I can't remember why (and he is in better
> > >> position to explain it), status quo so far...
> > >>
> > >
> > > Just to be clear, I am talking about claiming the lost ones _before_
> > > the struct is further extended with a reserved :31 (or whatever) as
> > > opposed to going back and claiming gaps from the past. Maybe the
> > > former is OK.
> >
> > I think "reserved" or not doesn't change anything, name it or not the
> > hole is there in any case.
> > Why extending firstbit:1;reserved:31 to e.g.
> > firstbit:1;secondbit:1;reserved:30 would be more compatible than the
> > implicit firstbit:1;secondbit:1 ?
> > Both should be allowed IMHO.
>
> Speculating only, it seems like there is a gradient of risk:
>
> - Old unused bits we try to repurpose that someone is squatting on
> - New unused bits we try to claim now (this is the case for the
> recent single bit field)
> - Unused bits that are explicitly marked as reserved when the first
> bit field is defined.
>
My sole concern was whether the addition of c below...
struct {
int a:2;
int b:2;
int c:2; /* Added */
}
...ever assured that the two bits of c will not displace a or b, and this
has never been a concern on Intel implementatins. Actually Eric you
have more background on big endian and odd word size architectures
than I do :) I've never found a reference that assures us of this, maybe
things have changed in very recent C specs?
Re: svn commit: r1828926 - in /httpd/httpd/trunk: CHANGES
docs/manual/mod/mod_proxy.xml include/ap_mmn.h modules/proxy/mod_proxy.c
modules/proxy/mod_proxy.h modules/proxy/mod_proxy_http.c
Posted by Eric Covener <co...@gmail.com>.
On Tue, Jun 26, 2018 at 9:02 AM Yann Ylavic <yl...@gmail.com> wrote:
>
> On Tue, Jun 26, 2018 at 2:48 PM, Eric Covener <co...@gmail.com> wrote:
> > On Tue, Jun 26, 2018 at 8:37 AM Yann Ylavic <yl...@gmail.com> wrote:
> >>
> >> On Mon, Jun 25, 2018 at 10:49 PM, Eric Covener <co...@gmail.com> wrote:
> >> >
> >> > Bill or Yann, do you remember the specific gotcha with setting aside
> >> > addl bits and re-using them later?
> >>
> >> I've never thought it was an issue (re compat) to add some bit(s) in a
> >> bitfield if there is a hole, wherever this field is in the struct.
> >> It doesn't change the size and there is no way for the user to have
> >> used the address of any bit in the first place (it can't break
> >> anything IMHO).
> >> Bill objected to this, I can't remember why (and he is in better
> >> position to explain it), status quo so far...
> >>
> >
> > Just to be clear, I am talking about claiming the lost ones _before_
> > the struct is further extended with a reserved :31 (or whatever) as
> > opposed to going back and claiming gaps from the past. Maybe the
> > former is OK.
>
> I think "reserved" or not doesn't change anything, name it or not the
> hole is there in any case.
> Why extending firstbit:1;reserved:31 to e.g.
> firstbit:1;secondbit:1;reserved:30 would be more compatible than the
> implicit firstbit:1;secondbit:1 ?
> Both should be allowed IMHO.
Speculating only, it seems like there is a gradient of risk:
- Old unused bits we try to repurpose that someone is squatting on
- New unused bits we try to claim now (this is the case for the
recent single bit field)
- Unused bits that are explicitly marked as reserved when the first
bit field is defined.
Re: svn commit: r1828926 - in /httpd/httpd/trunk: CHANGES
docs/manual/mod/mod_proxy.xml include/ap_mmn.h modules/proxy/mod_proxy.c
modules/proxy/mod_proxy.h modules/proxy/mod_proxy_http.c
Posted by Yann Ylavic <yl...@gmail.com>.
On Tue, Jun 26, 2018 at 2:48 PM, Eric Covener <co...@gmail.com> wrote:
> On Tue, Jun 26, 2018 at 8:37 AM Yann Ylavic <yl...@gmail.com> wrote:
>>
>> On Mon, Jun 25, 2018 at 10:49 PM, Eric Covener <co...@gmail.com> wrote:
>> >
>> > Bill or Yann, do you remember the specific gotcha with setting aside
>> > addl bits and re-using them later?
>>
>> I've never thought it was an issue (re compat) to add some bit(s) in a
>> bitfield if there is a hole, wherever this field is in the struct.
>> It doesn't change the size and there is no way for the user to have
>> used the address of any bit in the first place (it can't break
>> anything IMHO).
>> Bill objected to this, I can't remember why (and he is in better
>> position to explain it), status quo so far...
>>
>
> Just to be clear, I am talking about claiming the lost ones _before_
> the struct is further extended with a reserved :31 (or whatever) as
> opposed to going back and claiming gaps from the past. Maybe the
> former is OK.
I think "reserved" or not doesn't change anything, name it or not the
hole is there in any case.
Why extending firstbit:1;reserved:31 to e.g.
firstbit:1;secondbit:1;reserved:30 would be more compatible than the
implicit firstbit:1;secondbit:1 ?
Both should be allowed IMHO.
Re: svn commit: r1828926 - in /httpd/httpd/trunk: CHANGES
docs/manual/mod/mod_proxy.xml include/ap_mmn.h modules/proxy/mod_proxy.c
modules/proxy/mod_proxy.h modules/proxy/mod_proxy_http.c
Posted by Eric Covener <co...@gmail.com>.
On Tue, Jun 26, 2018 at 8:37 AM Yann Ylavic <yl...@gmail.com> wrote:
>
> On Mon, Jun 25, 2018 at 10:49 PM, Eric Covener <co...@gmail.com> wrote:
> >
> > Bill or Yann, do you remember the specific gotcha with setting aside
> > addl bits and re-using them later?
>
> I've never thought it was an issue (re compat) to add some bit(s) in a
> bitfield if there is a hole, wherever this field is in the struct.
> It doesn't change the size and there is no way for the user to have
> used the address of any bit in the first place (it can't break
> anything IMHO).
> Bill objected to this, I can't remember why (and he is in better
> position to explain it), status quo so far...
>
Just to be clear, I am talking about claiming the lost ones _before_
the struct is further extended with a reserved :31 (or whatever) as
opposed to going back and claiming gaps from the past. Maybe the
former is OK.
Re: svn commit: r1828926 - in /httpd/httpd/trunk: CHANGES
docs/manual/mod/mod_proxy.xml include/ap_mmn.h modules/proxy/mod_proxy.c
modules/proxy/mod_proxy.h modules/proxy/mod_proxy_http.c
Posted by Yann Ylavic <yl...@gmail.com>.
On Mon, Jun 25, 2018 at 10:49 PM, Eric Covener <co...@gmail.com> wrote:
>
> Bill or Yann, do you remember the specific gotcha with setting aside
> addl bits and re-using them later?
I've never thought it was an issue (re compat) to add some bit(s) in a
bitfield if there is a hole, wherever this field is in the struct.
It doesn't change the size and there is no way for the user to have
used the address of any bit in the first place (it can't break
anything IMHO).
Bill objected to this, I can't remember why (and he is in better
position to explain it), status quo so far...
>
> 2.4.x currently has a single bit bitfield at the end of the server_rec.
Yes, I think there is much less interest in using bitfields if we
can't extend them.
Regards,
Yann.
Re: svn commit: r1828926 - in /httpd/httpd/trunk: CHANGES
docs/manual/mod/mod_proxy.xml include/ap_mmn.h modules/proxy/mod_proxy.c
modules/proxy/mod_proxy.h modules/proxy/mod_proxy_http.c
Posted by Eric Covener <co...@gmail.com>.
On Wed, Apr 11, 2018 at 4:05 PM Yann Ylavic <yl...@gmail.com> wrote:
>
> On Wed, Apr 11, 2018 at 9:14 PM, Eric Covener <co...@gmail.com> wrote:
> >> --- httpd/httpd/trunk/modules/proxy/mod_proxy.h (original)
> >> +++ httpd/httpd/trunk/modules/proxy/mod_proxy.h Wed Apr 11 19:11:52 2018
> >> @@ -459,6 +459,8 @@ typedef struct {
> >> char secret[PROXY_WORKER_MAX_SECRET_SIZE]; /* authentication secret (e.g. AJP13) */
> >> char upgrade[PROXY_WORKER_MAX_SCHEME_SIZE];/* upgrade protocol used by mod_proxy_wstunnel */
> >> char hostname_ex[PROXY_RFC1035_HOSTNAME_SIZE]; /* RFC1035 compliant version of the remote backend address */
> >> + apr_size_t response_field_size; /* Size of proxy response buffer in bytes. */
> >> + unsigned int response_field_size_set:1;
> >> } proxy_worker_shared;
> >
> >
> > If this is for trunk only, should I move the bit field up and call it
> > major? I don't plan to backport it.
>
> Maybe the backport is needed to resolve PR 62196 altogether?
>
> > Whether I move it or not, should I reserve the next range of bytes after it?
>
> Would be nice to rearrange the struct for trunk/2.next.
> As for bitfields I'm not sure it helps reserving names for unused bits
> since we can't extend them in stable versions anyway (I wish we could
> given that it doesn't change any size/address and bits themselves have
> no address, but IIRC from an earlier discussion with Bill it's not an
> option)
Bill or Yann, do you remember the specific gotcha with setting aside
addl bits and re-using them later?
2.4.x currently has a single bit bitfield at the end of the server_rec.
--
Eric Covener
covener@gmail.com
Re: svn commit: r1828926 - in /httpd/httpd/trunk: CHANGES
docs/manual/mod/mod_proxy.xml include/ap_mmn.h modules/proxy/mod_proxy.c
modules/proxy/mod_proxy.h modules/proxy/mod_proxy_http.c
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Apr 11, 2018 at 10:05 PM, Yann Ylavic <yl...@gmail.com> wrote:
> On Wed, Apr 11, 2018 at 9:14 PM, Eric Covener <co...@gmail.com> wrote:
>>> --- httpd/httpd/trunk/modules/proxy/mod_proxy.h (original)
>>> +++ httpd/httpd/trunk/modules/proxy/mod_proxy.h Wed Apr 11 19:11:52 2018
>>> @@ -459,6 +459,8 @@ typedef struct {
>>> char secret[PROXY_WORKER_MAX_SECRET_SIZE]; /* authentication secret (e.g. AJP13) */
>>> char upgrade[PROXY_WORKER_MAX_SCHEME_SIZE];/* upgrade protocol used by mod_proxy_wstunnel */
>>> char hostname_ex[PROXY_RFC1035_HOSTNAME_SIZE]; /* RFC1035 compliant version of the remote backend address */
>>> + apr_size_t response_field_size; /* Size of proxy response buffer in bytes. */
>>> + unsigned int response_field_size_set:1;
>>> } proxy_worker_shared;
>>
>>
>> If this is for trunk only, should I move the bit field up and call it
>> major? I don't plan to backport it.
>
> Maybe the backport is needed to resolve PR 62196 altogether?
Scratch that, this commit doesn't fix the case where '\n' is within
the ENOSPC brigade but only comments on the issue.
Re: svn commit: r1828926 - in /httpd/httpd/trunk: CHANGES
docs/manual/mod/mod_proxy.xml include/ap_mmn.h modules/proxy/mod_proxy.c
modules/proxy/mod_proxy.h modules/proxy/mod_proxy_http.c
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Apr 11, 2018 at 9:14 PM, Eric Covener <co...@gmail.com> wrote:
>> --- httpd/httpd/trunk/modules/proxy/mod_proxy.h (original)
>> +++ httpd/httpd/trunk/modules/proxy/mod_proxy.h Wed Apr 11 19:11:52 2018
>> @@ -459,6 +459,8 @@ typedef struct {
>> char secret[PROXY_WORKER_MAX_SECRET_SIZE]; /* authentication secret (e.g. AJP13) */
>> char upgrade[PROXY_WORKER_MAX_SCHEME_SIZE];/* upgrade protocol used by mod_proxy_wstunnel */
>> char hostname_ex[PROXY_RFC1035_HOSTNAME_SIZE]; /* RFC1035 compliant version of the remote backend address */
>> + apr_size_t response_field_size; /* Size of proxy response buffer in bytes. */
>> + unsigned int response_field_size_set:1;
>> } proxy_worker_shared;
>
>
> If this is for trunk only, should I move the bit field up and call it
> major? I don't plan to backport it.
Maybe the backport is needed to resolve PR 62196 altogether?
> Whether I move it or not, should I reserve the next range of bytes after it?
Would be nice to rearrange the struct for trunk/2.next.
As for bitfields I'm not sure it helps reserving names for unused bits
since we can't extend them in stable versions anyway (I wish we could
given that it doesn't change any size/address and bits themselves have
no address, but IIRC from an earlier discussion with Bill it's not an
option). It doesn't prevent us from joining the existing ones for
2.next, though.
So +1 for me, including for an overall (optimized for size/holes)
moving of fields.
Re: svn commit: r1828926 - in /httpd/httpd/trunk: CHANGES
docs/manual/mod/mod_proxy.xml include/ap_mmn.h modules/proxy/mod_proxy.c
modules/proxy/mod_proxy.h modules/proxy/mod_proxy_http.c
Posted by Jim Jagielski <ji...@jaguNET.com>.
If only for trunk then I would say Yes, lets optimize these struct fields.
> On Apr 11, 2018, at 3:14 PM, Eric Covener <co...@gmail.com> wrote:
>
>> --- httpd/httpd/trunk/modules/proxy/mod_proxy.h (original)
>> +++ httpd/httpd/trunk/modules/proxy/mod_proxy.h Wed Apr 11 19:11:52 2018
>> @@ -459,6 +459,8 @@ typedef struct {
>> char secret[PROXY_WORKER_MAX_SECRET_SIZE]; /* authentication secret (e.g. AJP13) */
>> char upgrade[PROXY_WORKER_MAX_SCHEME_SIZE];/* upgrade protocol used by mod_proxy_wstunnel */
>> char hostname_ex[PROXY_RFC1035_HOSTNAME_SIZE]; /* RFC1035 compliant version of the remote backend address */
>> + apr_size_t response_field_size; /* Size of proxy response buffer in bytes. */
>> + unsigned int response_field_size_set:1;
>> } proxy_worker_shared;
>
>
> If this is for trunk only, should I move the bit field up and call it
> major? I don't plan to backport it.
> Whether I move it or not, should I reserve the next range of bytes after it?
Re: svn commit: r1828926 - in /httpd/httpd/trunk: CHANGES
docs/manual/mod/mod_proxy.xml include/ap_mmn.h modules/proxy/mod_proxy.c
modules/proxy/mod_proxy.h modules/proxy/mod_proxy_http.c
Posted by Eric Covener <co...@gmail.com>.
> --- httpd/httpd/trunk/modules/proxy/mod_proxy.h (original)
> +++ httpd/httpd/trunk/modules/proxy/mod_proxy.h Wed Apr 11 19:11:52 2018
> @@ -459,6 +459,8 @@ typedef struct {
> char secret[PROXY_WORKER_MAX_SECRET_SIZE]; /* authentication secret (e.g. AJP13) */
> char upgrade[PROXY_WORKER_MAX_SCHEME_SIZE];/* upgrade protocol used by mod_proxy_wstunnel */
> char hostname_ex[PROXY_RFC1035_HOSTNAME_SIZE]; /* RFC1035 compliant version of the remote backend address */
> + apr_size_t response_field_size; /* Size of proxy response buffer in bytes. */
> + unsigned int response_field_size_set:1;
> } proxy_worker_shared;
If this is for trunk only, should I move the bit field up and call it
major? I don't plan to backport it.
Whether I move it or not, should I reserve the next range of bytes after it?