Re: Confusing behavior w/ buckets in connection filter
On 12/26/2016 4:40 PM, Eric Covener wrote: > Did you see Jim just imported a third-party module for this? Argh! I didn't until you mentioned this, hahaha! Did I miss a note about it on list? Oh well... learning something is never a loss. Looks to be a more complete patch since it handles the v2 protocol versus what I was writing in mod_remoteip. Just glad to have it in place. -- Daniel Ruggeri
Re: Confusing behavior w/ buckets in connection filter
On Mon, Dec 26, 2016 at 5:38 PM, Daniel Ruggeri wrote: > On 12/26/2016 1:59 PM, Eric Covener wrote: >> or changing the # of bytes when you see yourself get called by >> mod_ssl? Not sure. > > > Actually, this is the most sane idea by far. The PROXY protocol spec > even helpfully gives you an idea on how many bytes may be sent in such a > header and also specifies that they should be sent all at once. No > reason to try to deal with multiple invocations of the filtering > function, etc. > > Thanks for the sanity check and pointer! I'll follow up with a patch for > review shortly. Did you see Jim just imported a third-party module for this? -- Eric Covener [email protected]
Re: Confusing behavior w/ buckets in connection filter
On 12/26/2016 1:59 PM, Eric Covener wrote: > or changing the # of bytes when you see yourself get called by > mod_ssl? Not sure. Actually, this is the most sane idea by far. The PROXY protocol spec even helpfully gives you an idea on how many bytes may be sent in such a header and also specifies that they should be sent all at once. No reason to try to deal with multiple invocations of the filtering function, etc. Thanks for the sanity check and pointer! I'll follow up with a patch for review shortly. -- Daniel Ruggeri
Re: Confusing behavior w/ buckets in connection filter
On Mon, Dec 26, 2016 at 2:56 PM, Eric Covener wrote: > On Mon, Dec 26, 2016 at 2:31 PM, Daniel Ruggeri wrote: >> This output is immediately after apr_bucket_read(b, &tmp_buf, &nbytes, >> APR_BLOCK_READ);... indeed, nbytes and the length of the bucket agree >> but there are 48 characters available (in this example) in the buffer. > > I don't know why it would be 11 instead of something like 5 for an SSL > record header, but it's probably that mod_ssl is asking for fewer > bytes (last parm in ap_get_brigade) and the core input filter has > stashed excess bytes away for the next read. You should pretend it's > really only the 11 bytes and call ap_get_brigade again. or changing the # of bytes when you see yourself get called by mod_ssl? Not sure. -- Eric Covener [email protected]
Re: Confusing behavior w/ buckets in connection filter
On Mon, Dec 26, 2016 at 2:31 PM, Daniel Ruggeri wrote: > This output is immediately after apr_bucket_read(b, &tmp_buf, &nbytes, > APR_BLOCK_READ);... indeed, nbytes and the length of the bucket agree > but there are 48 characters available (in this example) in the buffer. I don't know why it would be 11 instead of something like 5 for an SSL record header, but it's probably that mod_ssl is asking for fewer bytes (last parm in ap_get_brigade) and the core input filter has stashed excess bytes away for the next read. You should pretend it's really only the 11 bytes and call ap_get_brigade again. -- Eric Covener [email protected]
Re: Confusing behavior w/ buckets in connection filter
On 12/26/2016 11:23 AM, Eric Covener wrote: > No good hint here, but I have found the gdb macros in .gdbinit to be > really helpful to show these details. > > (dump_brigade, dump_bucket IIRC) Hi, Eric; Right - that more or less confirms the confusion. There's only one bucket in the brigade (which seems odd) and it believes it's 11 bytes in length. (gdb) dump_brigade bb dump of brigade 0x7fffd8007630 | type (address)| length | data addr | contents | rc 0 | HEAP (0x7fffd8000928) | 11 | 0x7fffd80009c8 | [PROXY TCP4 ] | 2 end of brigade (gdb) dump_bucket b bucket=HEAP (0x7fffd8000928) length=11 data=0x7fffd80009c8 contents=[PROXY TCP4 ] rc=2 (gdb) p nbytes $13 = 11 (gdb) p tmp_buf $14 = 0x7fffd801a0d8 "PROXY TCP4 192.168.0.103 172.17.0.2 44585 82\r\n\026\003" (gdb) call strlen(tmp_buf) $15 = 48 This output is immediately after apr_bucket_read(b, &tmp_buf, &nbytes, APR_BLOCK_READ);... indeed, nbytes and the length of the bucket agree but there are 48 characters available (in this example) in the buffer. -- Daniel Ruggeri
Re: Confusing behavior w/ buckets in connection filter
On Mon, Dec 26, 2016 at 9:21 AM, Daniel Ruggeri wrote: > Hi, all; > >I'm hoping just for a quick sanity check here... when consuming > buckets from the brigade inside a connection filter, I've seen that the > bucket length doesn't *appear* to accurately represent what data has > been made available when SSL is used. > > const char *tmp_buf; > apr_size_t nbytes; > apr_bucket_read(b, &tmp_buf, &nbytes, APR_BLOCK_READ); > >The particular scenario is that apr_bucket_read tells me that 11 > bytes were read according to nbytes... but a print of the string stashed > in the buffer shows many more. In fact, all data that should be > available at this time appears to be there (about as I would expect). > This seems to only happen when using SSL, FWIW. I consistently see 11 > bytes as being read by apr_bucket_read... but all 48 expected bytes are > there (strlen as well as any other method of examining the input concurs). > >I'm sure I've made a goofy assumption or am thinking about this wrong > somewhere... but the mistake in my understanding escapes me. Any thoughts? No good hint here, but I have found the gdb macros in .gdbinit to be really helpful to show these details. (dump_brigade, dump_bucket IIRC)
