Re: DO NOT REPLY [Bug 45023] DEFLATE preventing 304 NOT MODIFIED response
On 19 Aug 2008, at 14:41, [EMAIL PROTECTED] wrote: --- Comment #5 from rahul [EMAIL PROTECTED] 2008-08-19 06:41:51 PST --- Created an attachment (id=22453) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=22453) A POC slightly better than the above conf lines, Adds an input filter ETAG that can be used like below, along with DEFLATE to let apache recognize ($1)-gzip as $1 AddInputFilter ETAG .txt AddOutputFilterByType DEFLATE text/plain Neat little fix (insofar as that problem admits of a neat fix). But I dislike using an input filter just to manipulate request headers (that's what processing hooks are for), and the sysop shouldn't have to configure it. Does something bad happen if you put the check in a post_read_request hook instead? -- Nick Kew
Re: [PATCH] Dynamic locking upcalls in mod_ssl
On Wed, Aug 20, 2008 at 10:36:37AM -0400, Sander Temme wrote: On Aug 18, 2008, at 5:18 AM, Joe Orton wrote: So generally pconf is the right pool to use, along with a cleanup registered against that pool which sets the callbacks to NULL. Yes, with the cleanup it no longer hangs. What about stashing a pool reference in a global, is that a red flag? Given that the lifetime of the callbacks is now constrained, is the new global pool still needed? Also any reason to put the structure in ssl_private.h rather than the .c file directly? joe
Re: [PATCH] Dynamic locking upcalls in mod_ssl
-Ursprüngliche Nachricht- Von: Joe Orton Gesendet: Donnerstag, 21. August 2008 13:41 An: dev@httpd.apache.org Betreff: Re: [PATCH] Dynamic locking upcalls in mod_ssl On Wed, Aug 20, 2008 at 10:36:37AM -0400, Sander Temme wrote: On Aug 18, 2008, at 5:18 AM, Joe Orton wrote: So generally pconf is the right pool to use, along with a cleanup registered against that pool which sets the callbacks to NULL. Yes, with the cleanup it no longer hangs. What about stashing a pool reference in a global, is that a red flag? Given that the lifetime of the callbacks is now constrained, is the new global pool still needed? Where does this patch use a global pool? It keeps a reference on the pconf pool in a global variable, but it no longer creates a global pool. Or do I miss your point? Regards Rüdiger
Re: Dropping mod_sed into /trunk/ ?
On Wed, Aug 20, 2008 at 6:53 PM, Nick Kew [EMAIL PROTECTED] wrote: Any thoughts on dropping it in to trunk Is it best to preserve the current files/filenames (sed.h, libsed.h, sed0.c, etc.) to better reflect the history of that code, or should the files be combined/renamed to something that makes more sense for an Apache module that shares space with a lot of other modules? (I'm assuming this goes into modules/filters and not its own modules/sed.)
Re: [PATCH] Dynamic locking upcalls in mod_ssl
On Thu, Aug 21, 2008 at 01:49:35PM +0200, Plüm, Rüdiger, VF-Group wrote: Given that the lifetime of the callbacks is now constrained, is the new global pool still needed? Where does this patch use a global pool? It keeps a reference on the pconf pool in a global variable, but it no longer creates a global pool. Or do I miss your point? Oh, sorry, I missed that the dynlockpool is now parented off pconf. Ignore me and carry on ;) joe
Re: Dropping mod_sed into /trunk/ ?
On Thu, Aug 21, 2008 at 1:53 PM, Jeff Trawick [EMAIL PROTECTED] wrote: On Wed, Aug 20, 2008 at 6:53 PM, Nick Kew [EMAIL PROTECTED] wrote: Any thoughts on dropping it in to trunk Is it best to preserve the current files/filenames (sed.h, libsed.h, sed0.c, etc.) to better reflect the history of that code, or should the files be combined/renamed to something that makes more sense for an Apache module that shares space with a lot of other modules? (I'm assuming this goes into modules/filters and not its own modules/sed.) Renaming them to fit better in for the apache file tree seems a good idea. If its not done it will probably get done at some point in the future anyway. ~Jorge
Re: Dropping mod_sed into /trunk/ ?
| Any thoughts on dropping it in to trunk, with a view | to including it as standard in 2.4 in due course? | | mod_sed is much more than a mere string-or-regexp search-and-replace What happens to mod_substitute? especially since what substitute provides seems to be a strict subset of mod_sed ? rahul -- 1. e4 _
Re: Dropping mod_sed into /trunk/ ?
On Aug 20, 2008, at 6:53 PM, Nick Kew wrote: A little while ago, Basant Kukreja published mod_sed under the Apache license. He's now also written a blog entry that could become the basis for a tutorial into how mod_sed is much more than a mere string-or-regexp search-and-replace filter: http://blogs.sun.com/basant/entry/using_mod_sed_to_filter I happen to know that Basant and Sun will be happy for us to adopt mod_sed, and I think that with that blog entry reworked into a howto doc, it'll add real value to httpd. Any thoughts on dropping it in to trunk, with a view to including it as standard in 2.4 in due course? We will need, of course, the IP clearance issues resolved.
Re: svn commit: r686809 - /httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c
On Aug 19, 2008, at 11:44 PM, William A. Rowe, Jr. wrote: William A. Rowe, Jr. wrote: Different issue; different response. Bill Barker wrote: Nick Kew [EMAIL PROTECTED] wrote in message -1. Semicolon is a perfectly valid character in a session-id, so that risks breaking other apps. The fact that Tomcat treats it as a separator doesn't commit other appservers to do the same. No, an un-escaped semicolon is a reserved character by RFC 2396, section 2.2. Since RFC 2616 section 3.2.1 uses 2396 as a reference, then an un-escaped semicolon isn't valid in a session-id. Sorry, I answered too quickly, everything in the reserved set have two meanings in the context of the URI reserved= ; | / | ? | : | @ | | = | + | $ | , So let's study ;'s meaning 3.3. Path Component The path component contains data, specific to the authority (or the scheme if there is no authority component), identifying the resource within the scope of that scheme and authority. path = [ abs_path | opaque_part ] path_segments = segment *( / segment ) segment = *pchar *( ; param ) param = *pchar pchar = unreserved | escaped | : | @ | | = | + | $ | , The path may consist of a sequence of path segments separated by a single slash / character. Within a path segment, the characters /, ;, =, and ? are reserved. Each path segment may include a sequence of parameters, indicated by the semicolon ; character. The parameters are not significant to the parsing of relative references. This is not what Jim's patch represented, so I concur with Nick, -1 to the patch committed. Please note that get_path_param() is ONLY used to get the sticky route via the session data and only in find_session_route(). In any case, I agree that both solutions are non-optimal... This leads me to believe that whether we should treat ';' as special for session/route data should be runtime configurable. I propose a simple envar... Sound OK?
Re: Dropping mod_sed into /trunk/ ?
On 21 Aug 2008, at 13:02, rahul wrote: | Any thoughts on dropping it in to trunk, with a view | to including it as standard in 2.4 in due course? | | mod_sed is much more than a mere string-or-regexp search-and- replace What happens to mod_substitute? especially since what substitute provides seems to be a strict subset of mod_sed ? That's a decision that can wait for 2.4, by which time we should have more user feedback to base it on. -- Nick Kew
Re: svn commit: r686809 - /httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c
On 21 Aug 2008, at 13:39, Jim Jagielski wrote: In any case, I agree that both solutions are non-optimal... This leads me to believe that whether we should treat ';' as special for session/route data should be runtime configurable. I propose a simple envar... Sound OK? +1. (assuming I understand your meaning aright) -- Nick Kew
Re: Dropping mod_sed into /trunk/ ?
On 21 Aug 2008, at 13:28, Jim Jagielski wrote:
On Aug 20, 2008, at 6:53 PM, Nick Kew wrote:
A little while ago, Basant Kukreja published mod_sed under the
Apache license. He's now also written a blog entry that could
become the basis for a tutorial into how mod_sed is much more
than a mere string-or-regexp search-and-replace filter:
http://blogs.sun.com/basant/entry/using_mod_sed_to_filter
I happen to know that Basant and Sun will be happy for us
to adopt mod_sed, and I think that with that blog entry
reworked into a howto doc, it'll add real value to httpd.
Any thoughts on dropping it in to trunk, with a view
to including it as standard in 2.4 in due course?
We will need, of course, the IP clearance issues resolved.
Of course we have a long-standing CCLA from Sun.
Basant, do we have an ICLA from you?
http://www.apache.org/licenses/icla.{txt|pdf}
(Technically it's sufficient that it's Apache-licensed, if we preserve
the third-party notices. But that's not really what's proposed :-)
--
Nick Kew
Re: [PATCH] Dynamic locking upcalls in mod_ssl
On Aug 21, 2008, at 7:41 AM, Joe Orton wrote: Yes, with the cleanup it no longer hangs. What about stashing a pool reference in a global, is that a red flag? Given that the lifetime of the callbacks is now constrained, is the new global pool still needed? As Rüdiger mentioned, the pool is no longer created out of a NULL parent. Putting in the cleanup allowed me to use pconf without hanging the parent on shutdown. It's still a global reference, because the prototypes of the OpenSSL callbacks don't allow me to pass user data back in. Also any reason to put the structure in ssl_private.h rather than the .c file directly? None. I'll move it. S. -- Sander Temme [EMAIL PROTECTED] PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: SNI in 2.2.x (Re: Time for 2.2.10?)
Den Wednesday 20 August 2008 13:10:52 skrev Nick Kew: On Wed, 20 Aug 2008 12:06:33 +0200 Oden Eriksson [EMAIL PROTECTED] wrote: FYI: This patch is applied in Mandriva Linux. Any feedback? Bug reports coming from their users? No reports so far. It was requested by our users though. If you'd said Debuntu or Deadrat+family, we might infer a user community big enough to rely on (FSreasonableVO rely). Not sure about Mandriva, but it's surely better than nothing. It seems clear that users *really* want it. I'd say that adds weight to the argument for including it and taking the risk. It might be worth a --with-SNI configuration option, which would label it as an experimental feature. BTW: In mandriva Cooker (current) you can do this: [EMAIL PROTECTED] /]# LC_ALL=C urpmi apache-mod_ No package named apache-mod_ The following packages contain apache-mod_: apache-mod_activex_filter apache-mod_annodex apache-mod_anticrack apache-mod_antispam apache-mod_apparmor apache-mod_apreq apache-mod_athena apache-mod_auth_cert apache-mod_auth_form apache-mod_auth_gforge apache-mod_auth_imap apache-mod_auth_kerb apache-mod_auth_memcookie apache-mod_auth_msfix apache-mod_auth_mysql apache-mod_auth_nds apache-mod_auth_ntlm_winbind apache-mod_auth_openid apache-mod_auth_openpgp apache-mod_auth_pgsql apache-mod_auth_pubtkt apache-mod_auth_radius apache-mod_auth_remote apache-mod_auth_sdb apache-mod_auth_shadow apache-mod_auth_token apache-mod_auth_xradius apache-mod_authenticache apache-mod_authn_bugzilla apache-mod_authn_dbd apache-mod_authn_dbi apache-mod_authn_imap apache-mod_authn_nufw apache-mod_authn_sasl apache-mod_authnz_external apache-mod_authz_ldap apache-mod_authz_unixgroup apache-mod_axis2 apache-mod_backtrace apache-mod_benchmark apache-mod_bt apache-mod_but apache-mod_bw apache-mod_bwshare apache-mod_cache apache-mod_cachem apache-mod_cband apache-mod_cfg_ldap apache-mod_cguard apache-mod_chm apache-mod_chroot apache-mod_cidr apache-mod_clamav apache-mod_coredumper apache-mod_countm apache-mod_crowd apache-mod_dav apache-mod_dav_repos apache-mod_dav_svn apache-mod_dbd apache-mod_dbi_pool apache-mod_defensible apache-mod_deflate apache-mod_delay apache-mod_diagnostics apache-mod_disk_cache apache-mod_dns apache-mod_dnsbl apache-mod_dnsbl_lookup apache-mod_dnssd apache-mod_domaintree apache-mod_dontdothat apache-mod_encoding apache-mod_estraier apache-mod_evasive apache-mod_extract_forwarded apache-mod_fakessl apache-mod_fastcgi apache-mod_fcgid apache-mod_file_cache apache-mod_form apache-mod_fortress apache-mod_ftp apache-mod_ftpd apache-mod_geo apache-mod_geoip apache-mod_gnutls apache-mod_gzip_disk apache-mod_httpbl apache-mod_i18n apache-mod_ifier apache-mod_injection apache-mod_ip_count apache-mod_ipenv apache-mod_jsmin apache-mod_layout apache-mod_ldap apache-mod_ldap_userdir apache-mod_limitipconn apache-mod_line_edit apache-mod_load_average apache-mod_log_access apache-mod_log_data apache-mod_log_dbd apache-mod_log_rotate apache-mod_log_sql apache-mod_log_sqlite apache-mod_loopback apache-mod_lua apache-mod_macro apache-mod_mbox apache-mod_mem_cache apache-mod_memcache apache-mod_memcached apache-mod_memcached_cache apache-mod_mime_xattr apache-mod_mm_auth_ldap apache-mod_mono apache-mod_musicindex apache-mod_mya apache-mod_ndb apache-mod_nss apache-mod_ntlm apache-mod_parmguard apache-mod_perl apache-mod_php apache-mod_protection apache-mod_proxy apache-mod_proxy_ajp apache-mod_proxy_fcgi apache-mod_proxy_html apache-mod_proxy_xml apache-mod_pubcookie apache-mod_put apache-mod_python apache-mod_qos apache-mod_random apache-mod_replace apache-mod_roaming apache-mod_rpaf apache-mod_ruby apache-mod_ruid apache-mod_scgi apache-mod_schema apache-mod_scrmable apache-mod_security apache-mod_security2 apache-mod_sesehe apache-mod_sleep apache-mod_smbauth apache-mod_smtpd apache-mod_smtpd_rbl apache-mod_spam_die apache-mod_spin apache-mod_sqil apache-mod_ssl apache-mod_stats apache-mod_suexec apache-mod_suphp apache-mod_svn_view apache-mod_tcl apache-mod_tidy apache-mod_traf_thief apache-mod_transform apache-mod_umask apache-mod_upload apache-mod_userdir apache-mod_variety apache-mod_vdbh apache-mod_vhost_dbi apache-mod_vhost_hash_alias apache-mod_vhost_ldap apache-mod_vhost_limit apache-mod_vhost_mysql apache-mod_vhost_mysql1 apache-mod_vhost_pgsql apache-mod_vhost_sqlite3 apache-mod_vhs apache-mod_watchcat apache-mod_webfilter apache-mod_websh apache-mod_whatkilledus apache-mod_wsgi apache-mod_xhtml apache-mod_xhtml_neg apache-mod_xml2 apache-mod_xmlns apache-mod_xsendfile apache-mod_xslt2 apache-mod_xslt_filter apache-mod_ziplook apache-mod_zipread apache-mod_zrkadlo No idea about the other distros.
Re: Dropping mod_sed into /trunk/ ?
Thanks Nick for your initiative to make it part of Apache httpd. I am glad to
contribute to the Apache Software Foundation.
On Thu, Aug 21, 2008 at 02:04:14PM +0100, Nick Kew wrote:
On 21 Aug 2008, at 13:28, Jim Jagielski wrote:
On Aug 20, 2008, at 6:53 PM, Nick Kew wrote:
A little while ago, Basant Kukreja published mod_sed under the
Apache license. He's now also written a blog entry that could
become the basis for a tutorial into how mod_sed is much more
than a mere string-or-regexp search-and-replace filter:
http://blogs.sun.com/basant/entry/using_mod_sed_to_filter
I happen to know that Basant and Sun will be happy for us
to adopt mod_sed, and I think that with that blog entry
reworked into a howto doc, it'll add real value to httpd.
Any thoughts on dropping it in to trunk, with a view
to including it as standard in 2.4 in due course?
We will need, of course, the IP clearance issues resolved.
Of course we have a long-standing CCLA from Sun.
Basant, do we have an ICLA from you?
http://www.apache.org/licenses/icla.{txt|pdf}
(Technically it's sufficient that it's Apache-licensed, if we preserve
the third-party notices. But that's not really what's proposed :-)
I have not yet send the ICLA. I will send the signed document and post it in a
day or two.
--
Nick Kew
Regards,
Basant.
Re: SNI in 2.2.x (Re: Time for 2.2.10?)
Nick Kew [EMAIL PROTECTED]wrote: ... It might be worth a --with-SNI configuration option, which would label it as an experimental feature. I imagine the use of SNI would need to be configured in httpd.conf anyway, in the virtual host parts. Would an overall directive like: PermitVhostTLSWithSNI = yes be nicer? (with default Off.) Just a thought. iang smime.p7s Description: S/MIME Cryptographic Signature
[community] 2.3.0 alpha on October 1?
I'm thinking of tagging 2.3.0 alpha a month before we gather in New Orleans
for ApacheCon 2008/US http://us.apachecon.com/c/acus2008/ so that we can
begin to gather community feedback and actually /do/ something about it at
the hackathon.
Ok, I'm using 'we' sort of liberally, I'm training a day of httpd all day
Mon, and Rich takes the stage Tuesday which happens to be BarCamp day moreso
than hackathon. Since it doesn't look likely for me to do so much hacking,
the least I can do is offer to RM the first alpha.
Which brings me to the other half of [community], I'm proposing we hold
an Apache httpd {next} barcamp session for the community who are at
ApacheCon BarCamp on Tuesday to learn about what has changed, what might
change, and perhaps if we get enough folks to express interest ... about
what they want to change. Think in terms of Rich's What I hate about
Apache, x 15 voices or so :)
Thoughts?
