On Wed, Apr 11, 2018 at 9:14 PM, Eric Covener <cove...@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.

Reply via email to