osdir.com

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


On Wed, Apr 11, 2018 at 4:05 PM Yann Ylavic <ylavic.dev@xxxxxxxxx> wrote:
>
> On Wed, Apr 11, 2018 at 9:14 PM, Eric Covener <covener@xxxxxxxxx> 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@xxxxxxxxx