On Wed, Apr 11, 2018 at 4:05 PM Yann Ylavic <[email protected]> wrote: > > 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)
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 [email protected]
