On Wed, Apr 11, 2018 at 9:14 PM, Eric Covener <[email protected]> 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.
