Re: Can a module control the socket transport protocol?
On Tue, Jun 18, 2013 at 8:19 PM, Jon Leighton leigh...@cis.udel.edu wrote: I don't think simply swapping SCTP for TCP has anything to offer HTTP - that's just a starting point for me. I'm more interested in putting SCTP's streams to good use, such as possibly tying it into mod-spdy. I've hacked older versions of httpd to support HTTP over SCTP streams, but I was hoping to do something much cleaner, like a module. My main concern is that I don't see a way for a module to touch ap_listeners in listen.c, nor a way to create my own list of listeners that I could somehow pass off to httpd. I'll check out mod_ftp and mod_smtp as you suggested. Thanks very much. By the way, if you do have any luck with supporting SCTP as a module, and especially if you end up integrating at all with mod_spdy, I'd be very interested to hear more about it! Cheers, -Matthew (mod_spdy author)
Re: mod_ssl NPN API rejig (was Re: Intent to revert commit r1332643)
Hi Joe, Two questions about this change: - In modssl_register_npn, it appears that the code creates new npn_advertfns and npn_negofns arrays on every call, even if they already exist. This would seem to prevent multiple modules from registering callbacks. Presumably this is not intended? Am I misreading the code? - The old optional hooks were both declared as RUN_ALL, but the new implementation seems to stop calling callbacks as soon as one returns OK, which is different behavior than before. Is there a reason for this change? Best, -Matthew On Wed, May 29, 2013 at 10:36 AM, Joe Orton jor...@redhat.com wrote: Guenter, can you test if the attached compiles on Windows? It is nothing special so it should be OK. This redesigns the NPN API with a cheap and crappy callback interface which doesn't rely on the actual hooks API; it is not pretty but it avoids the inter-module hard linkage issue (which is even more crap and I should have noticed when committing, sorry about that). (Tested to compile and not segfault on Unix but no further, I'll mock up something to test properly.) Regards, Joe
Re: mod_ssl NPN API rejig (was Re: Intent to revert commit r1332643)
On Wed, May 29, 2013 at 11:14 AM, Joe Orton jor...@redhat.com wrote: On Wed, May 29, 2013 at 10:52:10AM -0400, Matthew Steele wrote: - In modssl_register_npn, it appears that the code creates new npn_advertfns and npn_negofns arrays on every call, even if they already exist. This would seem to prevent multiple modules from registering callbacks. Presumably this is not intended? Am I misreading the code? No, just a braino. Updated patch attached. Gotcha. I'm not seeing a new attachment, though? - The old optional hooks were both declared as RUN_ALL, but the new implementation seems to stop calling callbacks as soon as one returns OK, which is different behavior than before. Is there a reason for this change? I was wondering about this. The API description weakly implies that OK does something different to DECLINED in both cases, which is not true for RUN_ALL; so I presumed RUN_FIRST was desired. Are RUN_ALL semantics desired? Oops, yes, RUN_ALL semantics are desired; the misleading API description is my fault, sorry. (I confess I never really understood why RUN_ALL hooks accept both OK and DECLINED values, but then don't actually treat them any differently.) So probably we should update the doc comments. I'd be happy to draft new versions for those if that would be helpful, or not, as you prefer. Thanks, -Matthew
Re: mod_ssl NPN API rejig (was Re: Intent to revert commit r1332643)
On Wed, May 29, 2013 at 12:06 PM, Joe Orton jor...@redhat.com wrote: On Wed, May 29, 2013 at 11:37:14AM -0400, Matthew Steele wrote: Oops, yes, RUN_ALL semantics are desired; the misleading API description is my fault, sorry. (I confess I never really understood why RUN_ALL hooks accept both OK and DECLINED values, but then don't actually treat them any differently.) So probably we should update the doc comments. I'd be happy to draft new versions for those if that would be helpful, or not, as you prefer. OK vs DECLINED has always confused me too ;) How does this look? I've specified the behaviour for OK and DONE as return codes for both the callbacks; since the caller doesn't pay attention to errors I've left behaviour undefined for any other values. (Really attached this time) Looks good to me. Thanks! Cheers, -Matthew
Re: mod_deflate handling of empty initial brigade
On Tue, Jun 1, 2010 at 11:02 AM, Plüm, Rüdiger, VF-Group
ruediger.pl...@vodafone.com wrote:
The guide to writing output filters says:
https://httpd.apache.org/docs/trunk/developer/output-filters.h
tml#invocation
An output filter should never pass an empty brigade down the filter
chain. But, for good defensive programming, filters should be prepared
to accept an empty brigade, and do nothing.
IMHO do nothing means the same thing as pass it down the chain. So I think
mod_deflate does the correct thing here.
On the contrary, the link above specifically recommends putting the
following code snippet at the top of your output filter to suppress
the empty brigade (rather than pass it along to the next filter):
apr_status_t dummy_filter(ap_filter_t *f, apr_bucket_brigade *bb)
{
if (APR_BRIGADE_EMPTY(bb)) {
return APR_SUCCESS;
}
Does anyone know whether or not this is the right thing to do?
Cheers,
-Matt
Re: mod_deflate handling of empty initial brigade
I went ahead and created a bug entry/patch to make the (trivial) change to mod_deflate to make it conform to the Guide to writing output filters: https://issues.apache.org/bugzilla/show_bug.cgi?id=49369 Brian, does this patch to mod_deflate fix your problem? Nick, does this change seem reasonable to you? (I tried to follow the directions for patches on http://httpd.apache.org/dev/patches.html; apologies if I got it wrong...) Cheers, -Matt On Tue, Jun 1, 2010 at 11:54 AM, Nick Kew n...@webthing.com wrote: On 1 Jun 2010, at 15:53, Bryan McQuade wrote: According to this, mod_deflate should not pass the empty brigade along, and your module also should not be passing and empty brigade to mod_deflate. Eric, others, should we submit a patch to mod_deflate to change its behavior to be consistent with the output filter guide? +1. Looks like a trivial fix if this is the only error path concerned. And an extra-robustness check in core output filter can't hurt (can it?) -- Nick Kew
